Skip to main content
Governance data (gateway traces, activity events, audit-relevant spans and log records) lives in the same stores as every other trace your platform ingests, and its lifetime is governed by the same mechanism: tenant retention policies.

​
Tenant retention policies

Retention is configured per scope under Settings > Data Retention: an organization default, overridable per team and per project, most-specific wins. Periods are set in weeks, months, or years; deletion is partition-aligned (whole weeks) and enforced by the storage layer, not by an application worker that could be skipped. Policies can optionally apply retroactively to already-stored data. Configuring retention is an Enterprise capability; other plans use the platform default window. The full mechanics, including how deletion works and the self-hosted notes, live on Platform → Data Retention. Everything there applies to governance-origin data unchanged: a project holding gateway traffic follows its project policy, or its team’s, or the organization default.
Retention is scoped per organization, team, and project, never per ingestion source. Compliance notes that describe a per-source retention class map onto these scoped policies instead.

​
What is deliberately exempt: billing records

Spend records are not governed by tenant retention. They keep a fixed 13-month lifetime, declared in their own table definition, exempt from retention policies and from storage tiering configuration, and the exemption is pinned by a unit test. The reason is the direction of the risk: tenant retention is customer-shrinkable to weeks and can rewrite existing data retroactively. Billing records are invoiceable evidence; a 35-day tenant policy must never hard-delete the rows a rebilling customer reconciles invoices against. So the billing ledger sits outside the tenant map with its own fixed window, and 13 months is the reconciliation and replay contract stated in the billing docs. The same doctrine covers LangWatch’s own usage-metering ledgers. The knock-on worth knowing: trace data and billing data age out independently. A spend event whose underlying trace has aged out of a short tenant window still exists and still reconciles; only the drill-through to the trace is gone.

​
What this means for an auditor

  • Deletion is storage-enforced (partition-aligned TTL), not best-effort application cleanup.
  • Scope policies are explicit and auditable: who set which window on which scope is in the audit log.
  • Billing evidence survives tenant shortening: financial records keep their 13-month window regardless of how tight operational trace retention is set.
  • Longer windows are a plan capability: extended retention beyond the plan default is Enterprise, priced by stored volume (see Pricing).

​
Cross-references