A backup job can finish successfully while producing an empty, incomplete, misplaced, or unusable file. Monitoring backup freshness adds an independent check: it confirms that a recent artifact exists and carries enough evidence to deserve attention before the recovery window is missed.
Freshness is different from backup execution
Job status tells you that a process ran. Freshness tells you that the expected destination contains a new artifact within the required recovery point objective. Monitor both. A green scheduler entry is not proof that data reached storage.
Define an explicit freshness contract
For every backup set, record its expected cadence, maximum age, minimum plausible size, destination, retention class, and owner. Daily backups might warn after 26 hours and become critical after 30; hourly backups need tighter limits. Account for intentional maintenance windows without hiding real failures.
Expose a protected verification endpoint
Create an internal endpoint that reads backup metadata and returns the newest completed timestamp, artifact identifier, size, verification state, and storage location label. Do not return credentials, signed download links, customer data, or raw filenames containing sensitive information. Protect the trigger using the patterns in secure web cron endpoints.
Validate more than a timestamp
- Confirm the newest artifact is younger than the approved limit.
- Reject zero-byte or implausibly small files.
- Check that encryption and integrity metadata are present.
- Verify the expected database, tenant, or dataset identifier.
- Distinguish a completed backup from a partial upload.
When supported, compare an object checksum or manifest rather than downloading the full archive during every check.
Schedule the independent check
Run the web cron after the normal completion window, then repeat often enough to catch a missed cycle. Keep verification separate from the job that creates the backup; otherwise the same outage can silence both. The workflow complements automated database backups and scheduled API health checks.
Alert on meaningful evidence
Include the backup set, expected cadence, newest timestamp, observed age, size, last known good time, and runbook link. Require consecutive failures for transient storage errors, but escalate immediately when the recovery point is already outside policy. Send one recovery message after a fresh artifact passes all checks.
Test restoration, not only freshness
A recent file can still be corrupt. Schedule separate restore drills into an isolated environment and validate representative records, schema, and application startup. Freshness monitoring detects missing cycles quickly; restore testing proves recoverability. Neither replaces the other.
Handle time and storage carefully
Compare timestamps in UTC and use server-generated completion times. Follow redirects only to approved hosts, use short network timeouts, and restrict the checker to known storage paths. If verification overlaps, apply the locking guidance in preventing overlapping cron jobs.
Common mistakes
- Trusting the scheduler's success status.
- Checking modification time without size or completion state.
- Using upload start time as completion time.
- Exposing storage credentials through the monitoring response.
- Ignoring different cadences across backup sets.
- Never testing an actual restore.
Rollout checklist
- Inventory backup sets and recovery objectives.
- Define age, size, integrity, and completion rules.
- Build a protected metadata-only endpoint.
- Schedule an independent check after the normal backup window.
- Create deduplicated warning, critical, and recovery alerts.
- Test missing, partial, stale, and corrupt artifacts.
- Run periodic isolated restore drills.
- Review thresholds after data growth or schedule changes.
A useful freshness monitor does not merely look for a file. It verifies that the latest artifact arrived on time, looks plausible, and belongs to the expected backup set—giving responders time to repair a silent failure before it becomes a recovery crisis.