Telemetry retention is enforced by ClickHouse table TTLs, managed from Settings → General.
What the page shows
- Data Ingestion by Signal — current inbound volume per signal type; your early-warning for a misconfigured exporter flooding the platform.
- Storage Overview — on-disk size per table with compression ratios.
- Retention Policies — editable retention in days (1–3650) per table, grouped by storage tier. Saving applies a
TTL ALTERto the ClickHouse table directly.
Default retention
| Data | Default |
|---|---|
| Metrics (gauges and counters) | 30 days |
| Flow records | 14 days |
| Log messages | 30 days |
| Traces | 7 days |
| 5-minute metric rollups | 396 days (13 months) |
| Synthetic test results | 30 days |
Two details worth understanding:
- Flows and logs share a table, with a row-level TTL split by row type — so trimming flow retention doesn't cost you log history, and vice versa.
- Rollups outlive raw data by design. Full-resolution metrics age out at 30 days, but 5-minute downsampled rollups keep 13 months — and they preserve per-interface and per-host attributes, so capacity trending and year-over-year comparisons survive. When you shorten raw retention, you're trading away forensic granularity, not trend history.
Guidance
- Size flow retention to your incident-review habits: if postmortems regularly look back three weeks, 14 days is too short.
- Trace retention is the safest to keep short; traces are bulky and lose value fastest.
- After any change, watch Storage Overview for a few days — TTL deletions are background operations and disk reclaim is not instantaneous.
- Retention changes are admin-only actions (see Managing Users, Roles, and Access).