Data retention
What the platform prunes for you inside a project instance, how long each thing is kept, and which tables would otherwise grow forever.
Your project instance writes a lot besides your data: job records, webhook delivery logs, revision snapshots, request traces. None of it is useful indefinitely, and on D1 the database has one size budget for all of it — a table that grows forever eats the same quota your rows do.
So the platform prunes. This page is what it prunes and how long it keeps things, so you can tell “the platform tidied up” apart from “something deleted my data”.
What is kept, and for how long
Section titled “What is kept, and for how long”| What | Kept for | Notes |
|---|---|---|
| Revisions | 180 days | A full-row JSON snapshot is written on every update, so on a busy workspace this is usually the largest of these tables. It is also what powers per-row undo. |
| Jobs (completed / failed) | 30 days | Pending and active jobs are never pruned, however old — a queued job is work you are still waiting on, not a record. |
| Jobs (dead-letter) | 90 days | Kept longer on purpose: a dead-lettered job is something you probably still want to read. |
| Webhook deliveries | 30 days | Instance-wide, not per workspace — the table has no workspace column. |
| Activity log | 90 days | |
| Analytics events | 90 days | |
| Errors | 90 days | |
| Access audit | 30 days | |
| MCP audit | 30 days | |
| Traces | 7 days | The highest-volume and shortest-lived of the set. |
Pruning runs on the instance’s own schedule, in the background. It only removes rows past the window; nothing here touches your collections.
Your own data is never on this list
Section titled “Your own data is never on this list”Nothing above prunes rows in your collections. Retention applies only to the operational tables the instance keeps about itself. If you want your own records to expire, that is a schema decision — model it as a field and delete on your own schedule.
Where this shows up in your quota
Section titled “Where this shows up in your quota”Every table on this page counts toward the project’s database size, which you can see on the project’s Usage tab and which is capped by your plan. Revisions are the usual reason a database is larger than the data in it. If you are close to the cap and the number looks wrong for the rows you have, that table is the first place to look.
Storage that is already past its window is pruned on the next sweep, so a database briefly reads larger than its steady state — that is expected, not a leak.