Retention — Admin & Privacy

Storage limitation, made enforceable.

GDPR Art. 5(1)(e) requires data be kept no longer than necessary — this page shows the live retention windows and cron status that enforce it.

Per-table retention

Live values

Table	Window	Policy	Why this number
`analytics.events`	60 days (~2 months)	Hard DELETE on cron	Individual page views and journey transitions. Past this window, only the daily aggregate row survives.
`analytics.sessions`	60 days (~2 months)	Hard DELETE on cron	Per-visit metadata: started_at, last_seen, consent_tier. Same window as events to keep the join clean.
`analytics.user_events`	180 days (~6 months)	Hard DELETE on cron	The signed-in lane. Kept longer than the anonymous lane because it answers how an account is used over time — and erased immediately, regardless of age, when the account is deleted.
`analytics.consent_events`	395 days (~1.1 years)	Hard DELETE on cron	Proof of consent, or of its withdrawal. Thirteen months satisfies Art. 7(1) demonstrability without overshooting.
`analytics.bot_hits`	180 days (~6 months)	Hard DELETE on cron	Crawler and agent traffic. Holds no identifier of any kind — no IP, no hash, no session — so the window is set by what makes crawl cadence legible, not by minimisation.
`analytics.daily_page_stats`	365 days (~1 years)	Hard DELETE on cron	Pre-aggregated rollups (path / day / count). No individual visitor data, so they outlive the events they summarise.
`ai.turn`	30 days (~1 months)	Columns nulled on cron	The prompt as assembled, the history outline, the tool definitions and each tool result are blanked first; what the turn considered, included and cited stays as ids and sizes.
`ai.turn`	180 days (~6 months)	Hard DELETE on cron	The turn record itself — outcome, timings, provider attempts, citations. The conversations and messages are untouched by this sweep.
`ai.model_call`	180 days (~6 months)	Hard DELETE on cron	Per-request model, token and duration telemetry behind the cost views.
`ai.tool_call`	180 days (~6 months)	Hard DELETE on cron	Which tools each turn ran, with their arguments and outcome (the results themselves leave with the bodies).
`admin.audit_log`	365 days (~1 years)	Hard DELETE on cron	Append-only record of administrative actions. A long window on purpose — an audit trail that expires quickly is not much of an audit trail.
`mcp.call_log`	30 days (~1 months)	Columns nulled on cron	Caller-supplied query text and trace id are blanked first, while the dimensional signal stays. Minimising by column before by row is what keeps the longer row window unremarkable.
`mcp.call_log`	90 days (~3 months)	Hard DELETE on cron	The call row itself. By this point it carries no free text and no identifier at all — only tool, outcome, latency and registry version.
`desk.file`	30 days (~1 months)	Hard DELETE on cron	Files you have already deleted. A live file is never touched by this sweep; only the trash empties, and only after the window.
`desk.file_revision`	90 days (~3 months)	Hard DELETE on cron	Undo and version history for desk documents, pruned by age independently of the files themselves.
`notifications.notifications`	30 days (~1 months)	Archived on cron	Read notifications leave your active list at this point. They are not deleted yet.
`notifications.notifications`	90 days (~3 months)	Hard DELETE on cron	Archived notifications are removed entirely.
`jobs.job_execution`	90 days (~3 months)	Hard DELETE on cron	Run history for the scheduled jobs — start time, status, row count. Operational only; it holds no personal data.
`feedback.feedback`	—	Manual deletion only	User-authored content. We have no automatic expiry; you can request removal at any time and the operator deletes the row.
`auth.session`	—	Better Auth session expiry	Sessions expire on their own per Better Auth config. Logout invalidates immediately.

Cron status

Live

Loading…

Think this pattern could be better? Tell us how.

Leave feedback