Skip to main content
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

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.

​
What that means when you query

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.
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.

​
Query retention and your plan

Your plan carries a retention window, and log queries reaching further back than it are refused:
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.
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.

​
Deleting data early

There is no per-record or per-service delete, and no self-service “purge everything from yesterday”.
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. Filtering at the source also cuts your ingest volume, so it usually pays for itself.
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:
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.
Tail sampling keeps every erroring and slow trace and a fraction of the healthy ones. Most teams lose nothing they use. See Sampling.
DEBUG in production is rarely read and is frequently the majority of volume.
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.

​
Next

Plan limits

Ingest ceilings, rate limits and what happens when you reach one.

Sampling

Keep the traces that matter and drop the rest.

Platform architecture

Why the rollups exist and what they cost you.