Data Retention

Retention is defined by data class, not by a single period. Vagary does not publish one universal retention period, because the classes below are governed by different mechanisms with different purposes — and a single number across them would be architecturally false. Where a class has no automatic expiry today, this page says so.

1. What is automatically enforced

Each period below is enforced by the named component's own configuration, verified against the running service rather than a configuration file alone.

Data class	Retention	Enforced by
Security and forensic logs	1 year	Log store retention rules
Operational logs	30 days	Log store default retention
Debug and exporter logs	14 days	Log store retention rules
Metrics (short-term)	30 days	Prometheus, size-capped
Metrics (long-term)	12 months, full resolution	VictoriaMetrics
Distributed traces	72 hours	Tempo compactor eviction
Application error events	30 days	Daily partition drop
Mail platform binary logs	10 days	Database engine setting
Backups (see §3)	24 hourly, 14 daily, 8 weekly, 12 monthly, 5 yearly	Weekly prune job

2. What has no automatic expiry today

Stated plainly rather than omitted, because an absent row on a retention page reads as an oversight when it is in fact a deliberate current position:

Identity and account data — users, organizations, sessions, credentials and authentication factors are retained indefinitely by default. There is no database-level expiry job.
Audit and evidence records — the business audit trail carries no time-to-live and no purge job. This is deliberate: an audit record that expires on a timer is not an audit record.
Mailbox content — messages persist until a user or administrator deletes them. The mail platform's own garbage-collection interval is a filesystem maintenance setting, not a content-retention rule, and should not be read as one.

3. Backup retention is not data retention

These are different guarantees and conflating them is a common error. Deleting a record from a live system does not remove it from an existing backup; it stops being reachable through the product, and ages out of backups on the schedule in §1. A deletion request is satisfied against live systems and forward-going backups, not by rewriting history that has already been captured.

4. Per-organization configuration

The platform carries a per-organization retention configuration and a four-tier data lifecycle that never moves backward. No organization has configured a policy through it yet, so every class today follows the defaults above. Where a customer agreement specifies a different period, that agreement governs.

5. Deletion and export requests

Data subject access, export and erasure requests are handled through the compliance process described in our Privacy Policy and Data Deletion pages. That mechanism is live and in use, with a cooling-off period recorded per request.

6. What this page is not

These are current enforced defaults and current practice, not contractual retention guarantees. Binding retention terms belong in a signed agreement, where they can be scoped to a customer's data classes and jurisdiction. If you need a specific retention commitment, ask for it in the agreement rather than relying on this page.