Check results
Read check states, failure categories, selected artifacts, probes, notifications, and available evidence.
Loading documentation…
Powered by heyo
A check is one execution of a saved schedule, started by its cadence or manually. Its detail page brings together the configuration snapshot, selected artifact, status, logs, probes, messages, and available evidence.
| Status | Meaning |
|---|---|
| Queued | The check is waiting to be claimed by its selected worker |
| Leased | The worker has claimed the check and is preparing execution |
| Running | Download, restore, or validation work is in progress |
| Successful | All required stages and configured criteria passed |
| Timeout | The check exceeded its queue-wait or overall run limit |
| Infrastructure error | Worker or temporary execution infrastructure prevented completion, including a check whose start the worker did not confirm before the start-attempt limit (10 by default) |
| Configuration | The saved source, Secret reference, format, or other configuration could not be used |
| Download / file | File selection, freshness, size, download, or file handling failed |
| Restore | The database import failed |
| Probe | A health or validation probe failed, a query exceeded its own time limit, or a duration gate failed or stopped a stage |
| Quota limit | The check could not proceed under the applicable plan capacity |
| Other error | The check failed without a more specific customer-facing category |
Queued, leased, and running are nonterminal. The remaining statuses are terminal.
The Backup file card on General shows the file the worker actually selected: its name, full source address, downloaded size, listed modification time, and SHA-256 checksum. The address uses the source configuration saved when the check was dispatched, so later source edits do not change it.
The file checksum covers the downloaded bytes before decryption, decompression, or unpacking. It is separate from the SHA-256 digest of the check's JSON evidence. A failed restore can still have complete file details. If the download failed, the selected name may be available while downloaded size and checksum are missing. Older checks or workers may not provide this card.
On General, inspect Backup file and verify the schedule, worker, source, database settings, timing, and final status. Compare the actual selected file with the intended backup, not just the schedule's folder.
Review the configuration snapshot on the check. The linked Schedule opens the schedule's current configuration; later edits do not change the completed check's saved settings.
Use Logs to focus on download, restore, database, or health-probe output. Logs may be unavailable or incomplete when execution never reached that stage.
Open Probes and compare actual results, expected values, operators, and duration gates. A successful status is meaningful only in the context of those criteria.
Open Messages to see whether configured notifications were queued, delivered, or failed. Notification delivery does not alter the check result.
A successful check establishes that one selected artifact passed the configured process and gates. It does not prove all retained backups, all records, or application-level recovery. Preserve evidence and improve the gates when a check does not test a material recovery requirement.