Run records
No records loaded yet. Drop files, paste JSON, or load the shrinking-dump example.
.json run records here, or choose files.
Night-over-night
Waiting for records
Each night is classified the same way as backup-evidence check. A 20% size drop versus the previous night or the prior-night median is flagged, even when that night still reads as verified.
| Finished | Status | Size | vs previous | Flags |
|---|---|---|---|---|
| Nothing to compare yet. | ||||
Show markdown export
What this answers
- Why is my backup smaller than yesterday? — the search question this page is for.
- Isn't this what Healthchecks.io already does? — no: cron monitoring proves the job ran and exited 0, which a truncated archive also does.
- Isn't checking $? or systemd status good enough? — no: a backup that fills the disk and writes a 312-byte file still exits 0.
- The CLI still does the integrity read:
PYTHONPATH=src python3 -m backup_evidence.cli check runs/*.json --trend --format markdown
Common questions
Does a flagged night mean my backup is broken?
No. A flag means the archive shrank at least 20% against the previous night or the median of prior nights — it says nothing about whether the bytes that are there are restorable. A backup can exit 0, pass its own verification, and still get flagged here because it wrote noticeably less than usual; that gap is exactly what a green exit code hides.
Does this open my backup archive to check what's inside?
No. It only reads the fields already in your JSON run records — exit code, status, finished time, and artifact size — and never touches the archive itself. It cannot tell you whether a restore would actually work; only a real test restore can.
Why does it need more than one night of records?
The comparison is night-over-night: each row is judged against the previous night's size and the median of the nights before it. Load a single record and there is nothing to compare it to, so drop or paste at least two consecutive nights, or load the shrinking-dump example to see it work.
Does my run-record data leave my browser?
No. Files you drop or paste are parsed and compared entirely client-side; nothing is uploaded. The only thing kept is an anonymous local count of which buttons get used, which Do Not Track and Global Privacy Control turn off automatically.
What does "Require an end-to-end integrity read" change?
Most run records only carry an exit code and an artifact stat, so "verified" here means those agreed — it does not mean anything opened the file. If you recorded runs with backup-evidence record --verify-integrity, each record also carries an integrity result; turning this on reports any night without a conclusive intact read as inconclusive instead of verified, even if its exit code and size were fine. It never reads the archive itself — it only reads the integrity result already in the record you gave it.