Backup monitoring should answer three questions: did the scheduled job run, did it produce the expected backup, and can that backup be restored? A successful process exit tells you less than a successful restore.
Start with one backup job and write down the expected schedule, destination, retention requirements, and owner. Decide what evidence you need for each stage. This guide describes checks your own backup integration performs; ActionBox does not inspect or restore your backup data for you.
Monitor completion and recoverability separately
| Layer | Useful evidence | What it does not prove |
|---|---|---|
| Scheduling | A run started within its expected window | The backup completed |
| Completion | Backup command and destination checks passed | The data is restorable |
| Restore validation | A chosen backup restored and passed application checks | Every retained backup is healthy |
Give a restore drill its own schedule and completion signal. Otherwise, routine backup success can conceal a restore test that stopped running months ago.
Define success before adding a heartbeat
For a file-based backup, validate the artifact created by the current run rather than any file at the destination. Depending on your backup system, checks might include a completed upload, a readable manifest, an expected identifier, and an integrity verification supplied by the backup tool.
An empty file check alone is weak evidence. A nonempty backup can still be incomplete, encrypted with an unavailable key, or incompatible with the recovery environment. Use the validation supported by your actual backup system and document its limits.
Avoid sending database contents, filenames containing personal data, credentials, or backup URLs into monitoring payloads. A job name and a concise failure category are usually more useful for initial triage.
Send success only after validation
Send the start signal, run the backup, and check the new result. Send success only after those checks pass. If execution or validation fails, preserve that failure status and report failure where possible.
The monitor must also detect an absent signal. If the host never starts, an error-reporting step inside the backup script cannot run either. This is the same missing-execution problem covered in the cron troubleshooting guide.
Keep the backup command's result even if its monitoring signal fails to arrive. Record monitoring transport problems separately so operators can distinguish a failed backup from an uncertain reporting path.
Choose a realistic window
Use a schedule that matches when the backup is expected, a grace period based on normal launch variation, and a maximum runtime based on measured execution. A small daily export and a large weekly backup need different timeout settings.
Record observed durations over representative runs, including larger datasets. Revisit the threshold as the dataset grows. A consistently late backup deserves investigation even when increasing the grace period would silence the alert.
Connect the incident to a runbook
ActionBox's heartbeat monitoring guide describes Watches for missed signals, explicit failures, and runtime overruns. Confirm hosted availability through the Watch documentation before depending on the integration.
The runbook should tell the operator where to inspect the backup tool, how to identify the affected recovery point, and whether retrying is safe. A heartbeat recovery records that a signal resumed; it does not certify the historical backup or erase the need to investigate a missed recovery objective.
Test with a disposable backup
Use synthetic data in a separate destination. Exercise a successful run, a command failure, a validation failure, and an omitted scheduled run. Record the expected and observed monitor state for each case.
Restore a disposable backup into an isolated test environment and check the data. Publish the test procedure and actual observations if you want reusable evidence for your team. Label the dataset and environment clearly; a demonstration is not a customer reliability claim.
Create a free Source to begin setup, then confirm Watch availability before relying on monitoring.
