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’s window follows your core telemetry — logs, traces, metrics and everything derived from them. For those records the window is stamped onto each row as it is written, from the plan the organization is on at that moment, and the storage layer expires each row against its own stamp. The default is 30 days. Some data has its own fixed window instead, longer or shorter than the plan, and the table below says which. Where a fixed window is longer than your plan, that data is kept longer than your plan’s number; where it is shorter, it goes sooner. Those windows are the same for every plan today.
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.

​
Choosing a shorter retention

Your plan’s window is the most we keep, not the least. An admin can keep metrics, traces and logs for less time than the plan allows, under Retention controls on Settings → Retention (the Account section, beside Usage and Billing):
  • Per signal. Each signal has its own row: enter a number, pick Days or Months (a month is 30 days), and select that row’s Save. The value can be anything from 1 day to your plan’s window. The line under each row says whether it follows your plan or when it was last changed. Reset to plan returns a signal to your plan, including after a later upgrade.
  • Per service, for logs. Under the Logs row, Stream retentions lists rules that match resource attributes — for example service.name is one of checkout, payments, or deployment.environment is prod — and give matching logs their own number of days. Each row shows its selector the way Grafana writes one ({service.name=~"checkout|payments"}). Every condition in a rule must match. Rules are checked from the top and the first match wins; logs that match none use the Logs row’s value. Select Add stream retention to add one, the arrows to move one up or down, or the trash icon to remove one, then the Logs row’s Save.
  • Reducing retention is typed out. A save that keeps any data for less time than now asks you to type reduce retention before it goes through. Because the first match wins, that includes a save where no number went down: moving a shorter rule above a longer one, adding a rule above a longer one, or removing a longer rule each shortens the logs that rule used to claim.
A change applies to everything stored, not only to new data. As soon as you save a shorter period, data older than it stops being shown — in every page, chart, dashboard query and API answer — and a background job then permanently deletes it. Deleted data cannot be recovered. The row’s status line shows that job’s progress (“Removing stored data outside this period”), and says when stored data matches the setting.Lengthening retention keeps what is still stored for longer. It does not bring back data that was already deleted.
Deletion is not instant: it is carried out in the background, one table at a time, and on an account with a lot of stored data it can take a while. The data is hidden from the moment you save, whether or not it has been deleted yet. Nothing here can exceed the plan: a value above it is refused, and if the plan is later downgraded, data past the new plan’s window stops being shown without you changing the setting. Rollups that summarise logs kept for different lengths are kept for the longest of them, as above. Network flows and agent events always follow the plan. The same settings are available through the API at GET / PUT /api/account/retention (admin role to change them).

​
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 past it is not returned at any zoom level.Not returned is not the same as already erased. Expiry is a background operation, so a row can sit in storage for some hours after its window ends — the product stops answering with it at the window, not at the moment it is physically removed. The full-text copy that backs log search has its own index-level window, and the fixed-window data in the table above is kept for its own period whatever your plan says.
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

The time picker stops at your retention. It offers no window that starts before the oldest data your account keeps — the longest of your logs, traces and metrics settings, capped at the plan. A longer preset is shown greyed out, and a typed or calendar range that reaches further back is refused with the date it may start after. A link or saved view naming a longer window opens limited to what is kept, and the time controls say so. Log queries that reach further back than your logs are kept — your logs setting or its longest rule, capped at the plan — 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 best 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.For logs, ingest rules do the same inside aiAxonIQ: they remove, redact, mask or hash a field, or drop a log, before it is stored. They apply to logs received after the change, not to logs already stored.
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

Beyond a shorter retention for data you reread rarely, the lever you have is volume. In rough order of return:
Ingest rules drop logs you never read and remove large fields before they are stored, without a change on your side, and show how many logs and how many bytes they removed.
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.