Data retention
Run history, attempts, the audit log and sent alerts grow with every run, so cronpad deletes them after a retention window: 30 days by default, 7 days for response bodies. Jobs, users, keys and settings are never pruned. A background task deletes old rows in small batches and returns the space to the operating system, so pruning never delays scheduling.
Defaults
| Data | Kept for | Setting |
|---|---|---|
| Runs and their attempt records | 30 days | retention.runs |
| Response bodies and command output | 7 days, non-successful attempts only | retention.attempt_bodies, retention.store_success_bodies |
| Audit log | 30 days | retention.audit_log |
| Sent, failed and suppressed alerts | 30 days | retention.alert_outbox |
| Pending alerts | Until delivered | — |
| Daily statistics (dashboard charts) | 400 days | retention.job_stats_daily |
| Sessions | Until they expire | auth.session_lifetime |
| Jobs, workspaces, users, API keys, secrets, alert settings | Until you delete them | — |
Set any window to "0" on a self-hosted server to keep that data forever.
How pruning works
- Every 5 minutes, the janitor deletes expired rows in batches of 1,000, each in its own short transaction, and pauses whenever the database writer is busy.
- Charts don’t lose history: daily statistics are rolled up before the raw runs they summarize are deleted. Runs that are still running or deferred are kept until they finish.
- Freed space is returned to the filesystem incrementally, so the database files shrink rather than only grow.
- Monthly usage counts are independent of run history: pruning a run does not return a quota slot. Monthly usage records are kept for 400 days.
- Each pass is logged and counted in
cronpad.janitor.deleted.
Deleting a job
Deleting a job stops it immediately. Its runs remain visible in history until they age out under the same windows.
Estimating disk usage
A run with its attempt metadata takes roughly 300–500 bytes. Response bodies add up to 64 KiB each when stored.
| Runs per day | 30 days of runs (no bodies) |
|---|---|
| 10,000 | ~150 MB |
| 1,000,000 | ~10–15 GB |
Turning on store_success_bodies can multiply this many times over, depending on how large your endpoints’ responses are.
Workspace plans
On cronpad Cloud, run, response-body and audit-log retention follow the workspace’s plan; see editions. Self-hosted servers use the global settings above.