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

Your plan sets one retention window, and it applies to everything your telemetry produces. The window is stamped onto every record as it is written, from the plan the organization is on at that moment, and the storage layer expires each record against its own stamp. The default is 30 days.
The rollups do not outlive the data they summarise, and that is deliberate.As metrics arrive they are continuously pre-aggregated into one-minute and one-hour tables. Those tables once carried their own flat windows — 90 days and a year — regardless of the plan, which meant an organization whose raw records expired on day 7 still had per-minute aggregates of them three months later. A retention promise that holds for raw data and not for data derived from it is not a retention promise, so the rollups now carry the same window the rows beneath them did.Where an aggregate summarises records written under two different plans, it is kept for the longer of the two: over-retention is a bounded cost, and deleting data an organization is still entitled to is not recoverable.
Your own window is on Settings → Usage, next to your plan name. It is also what a log query is checked against — see below.

​
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 inside your retention window can be seen at full resolution; anything older is gone from every table, 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, and storage retention is the same number: they are read from the same plan field, so they do not normally diverge. 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.