> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Data retention

> How long each signal is kept, why metrics outlive logs by a year, and the difference between what is stored and what your plan lets you query.

Retention in aiAxonIQ is two separate things, and confusing them accounts for
most surprises:

* **Storage retention** — how long a row physically exists. Fixed per table.
* **Query retention** — how far back your plan permits you to ask. Set by your
  plan.

They are usually the same number. Where they differ, the smaller one wins, and
the reason your query returned nothing depends on which one it was.

## Storage retention by signal

| Data                           | Kept for                       |
| :----------------------------- | :----------------------------- |
| Logs                           | **30 days**                    |
| Traces and spans               | **30 days**                    |
| Metrics, at full resolution    | **30 days**                    |
| Metrics, one-minute rollup     | **90 days**                    |
| Metrics, one-hour rollup       | **365 days**                   |
| Error-rate rollups             | 90 days                        |
| AI-agent activity (AgentSight) | 30 days raw, 90 days rolled up |
| LLM request records            | 30 days raw, 90 days rolled up |

<Note>
  **Metrics outlive logs by a year, and that is not a mistake.**

  As metrics arrive they are continuously pre-aggregated into one-minute and
  one-hour tables. Those rollups are small, so keeping them for a year costs
  almost nothing — and a year of hourly points is exactly what capacity
  planning and trend analysis need.

  The raw samples behind them are large, so they go at 30 days like everything
  else. You keep the shape of last quarter without paying to keep every point
  in it.
</Note>

## What that means when you query

<Warning>
  **A wide time range answers at a coarser resolution.** A query spanning
  months reads the hourly rollup, so a 20-second spike inside it is averaged
  away — it is not missing, it is summarised.

  When you are hunting a brief event, narrow the range until you are inside the
  full-resolution window. Anything under 30 days old can be seen at full
  resolution; anything older cannot, at any zoom level.
</Warning>

There is a second, opposite effect on very *fresh* data. A record is written to
the raw table before the rollups covering it are complete, so a record from
thirty seconds ago can be visible on "last 15 minutes" and not yet on "last 7
days". Waiting a minute fixes it; widening the range does not. See
[Verify your data arrived](/get-started/verify-data).

## Query retention and your plan

Your plan carries a retention window, and log queries reaching further back
than it are refused:

```json theme={null}
{
  "error": "RETENTION_EXCEEDED",
  "message": "Your plan allows querying up to 30 days back."
}
```

This is a `400`, not an empty result — which is deliberate. An empty result
would be indistinguishable from "there was no traffic", and you would go
looking for a missing-data bug that does not exist.

<Info>
  **The default is 30 days**, which matches storage retention. A plan with a
  longer query window does not extend storage: full-resolution logs and traces
  still stop at 30 days, and what remains available beyond that is the metric
  rollups. Check your plan's window on **Settings → Usage**.
</Info>

## Deleting data early

There is no per-record or per-service delete, and no self-service "purge
everything from yesterday".

<Warning>
  **Do not send anything to aiAxonIQ you would need to delete on request.**
  Telemetry pipelines are append-only by design, and a log line with a customer
  email in it will sit in your account for its full retention.

  The place to fix this is the exporter, before it leaves your network. The
  OpenTelemetry Collector's `attributes`, `redaction` and `transform`
  processors drop or mask fields in flight — see
  [Collector configuration](/send-data/otel/collector-config). Filtering at the
  source also cuts your ingest volume, so it usually pays for itself.
</Warning>

If you need data removed — a credential committed to a log, a mistaken import —
contact support. Deleting an entire organization's telemetry is possible;
surgical deletion within one is not.

## Reducing what you store

Retention is fixed, so the lever you have is volume. In rough order of
return:

<AccordionGroup>
  <Accordion title="Drop health-check and metrics-scrape traffic" icon="filter">
    On a typical service these are the highest-frequency and lowest-value spans
    and log lines in the system. Filtering them at the Collector is usually the
    single biggest reduction available, and costs you nothing you would have
    looked at.
  </Accordion>

  <Accordion title="Sample traces" icon="percent">
    Tail sampling keeps every erroring and slow trace and a fraction of the
    healthy ones. Most teams lose nothing they use. See
    [Sampling](/send-data/otel/sampling).
  </Accordion>

  <Accordion title="Raise the log level in noisy services" icon="signal">
    `DEBUG` in production is rarely read and is frequently the majority of
    volume.
  </Accordion>

  <Accordion title="Control metric cardinality" icon="tags">
    A label carrying a user id, a request id or a raw URL path turns one metric
    into millions of series. This costs more than the samples do. See
    [Resource attributes](/send-data/otel/resource-attributes).
  </Accordion>
</AccordionGroup>

## Next

<CardGroup cols={3}>
  <Card title="Plan limits" icon="gauge" href="/concepts/limits">
    Ingest ceilings, rate limits and what happens when you reach one.
  </Card>

  <Card title="Sampling" icon="percent" href="/send-data/otel/sampling">
    Keep the traces that matter and drop the rest.
  </Card>

  <Card title="Platform architecture" icon="sitemap" href="/concepts/architecture">
    Why the rollups exist and what they cost you.
  </Card>
</CardGroup>