Retention — Admin & Privacy

Datenspeicherung, durchsetzbar gemacht.

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.

Aufbewahrung je Tabelle

Live values

Tabelle	Zeitfenster	Richtlinie	Begründung
`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…

Geht dieses Pattern noch besser? Sag uns, wie.

Feedback geben