# 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](editions.md). Self-hosted servers use the global settings above.