Why not a cron job?

Evidence is the product, not automation.

A cron job produces logs that you wrote, you host, and you can edit. An auditor has no reason to trust them. Restorable produces DSSE receipts signed by your Ed25519 key that a third party verifies independently, using the open-source restorable-verify CLI. No access to your infrastructure or ours required.

The structural difference: your cron logs are assertions you make about yourself. A signed receipt is a cryptographic artifact that an independent party can validate. An auditor assessing your NIS2, DORA, or ISO 27001 backup controls accepts the second. The first gets a follow-up question.

Drift detection across the fleet.

One script per database doesn't scale. When you have five databases across three environments, each with different restore quirks, you need a system that catches what individual scripts miss. Extension versions that differ between dump and restore. Collation changes after a libc update. A Postgres major version mismatch between source and target.

Restorable runs each restore in an isolated container with a matching engine version and reports per-source, per-check results in a single dashboard. One place to see whether every database in the fleet actually restores, not five separate log files in five different cron jobs.

Edge cases already solved.

Every restore script hits the same bugs eventually. If you're writing one, you'll rediscover each of these:

• Extension drift. The dump environment has pg_trgm 1.6; the restore target has 1.5. The restore fails, silently or loudly depending on the extension.
• Collation breakage. A libc update changes sort order. pg_restore exits 0, but indexes built on the old collation produce wrong query results. Your script reports success.
• Partial restore success. pg_restore exits 0 but half the tables are empty because --no-owner suppressed permission errors. Your script checks the exit code. The data is gone.
• Engine-level vs. application-level success. The restore completed. The tables exist. But the row count is half what it should be because a foreign key constraint was deferred and silently dropped rows. Without application-level checks, this reads as a pass.

Restorable runs application-level checks (row counts, index presence, NULL assertions, custom SQL) after every restore. Each check is recorded individually in the signed receipt. A cron script that only checks exit codes misses all of these.

The evidence trail is the deliverable.

An auditor doesn't accept "our cron job ran." They accept a signed, independently verifiable receipt with full metadata: engine version, backup hash, restore duration, individual check results, and a pass/fail verdict. Your CI logs are not that.

Each receipt is appended to a per-org transparency log with cryptographic inclusion and consistency proofs. The chain is tamper-evident. If a receipt is removed or modified after the fact, the proof breaks. A cron log in S3 or CloudWatch has no equivalent property.

You stop maintaining it.

Every backup cron job was lovingly written. None of them have been updated since. The S3 credentials rotated and nobody noticed for three months. The Postgres version upgraded and the restore script still targets the old major. The alert channel got archived and the failures went to /dev/null.

This is not a discipline problem. It's a priority problem. Backup verification is never the most important thing on the sprint. So the script rots. And when you need it, you discover the rot at 3 AM during the incident that was supposed to be easy to recover from.

Restorable runs the same verification every week, sends a weekly evidence email, and alerts on failure. The tool doesn't get deprioritized because it's not competing for your team's sprint capacity.