Axiom
Overview

ingestion_time

You can use ingestion_time to:

  • Detect delays or lags in data ingestion.
  • Filter events based on their ingestion window.
  • Audit data pipelines by comparing event time with ingestion time.

This function is especially useful when working with streaming or event-based data sources where ingestion delays are common and might affect alerting, dashboarding, or correlation accuracy.

Usage#

Syntax#

ingestion_time()

Parameters#

This function doesn’t take any parameters.

Returns#

A datetime value that represents when each record was ingested into Axiom.

Use case examples#

Use ingestion_time to identify delays between when an HTTP request occurred and when it was ingested into Axiom.

Query

['sample-http-logs']
| extend ingest_time = ingestion_time()
| extend delay = datetime_diff('second', ingest_time, _time)
| where delay > 1
| project _time, ingest_time, delay, method, uri, status

Run in Playground

Output

_time ingest_time delay method uri status
2025-06-10T12:00:00Z 2025-06-10T12:01:30Z 90 GET /api/products 200
2025-06-10T12:05:00Z 2025-06-10T12:06:10Z 70 POST /api/cart/add 201

This query calculates the difference between the ingestion time and event time, highlighting entries with more than 60 seconds delay.

Use ingestion_time to monitor ingestion lags for spans generated by services, helping identify pipeline slowdowns or delivery issues.

Query

['otel-demo-traces']
| extend ingest_time = ingestion_time()
| extend delay = datetime_diff('second', ingest_time, _time)
| summarize avg_delay = avg(delay) by ['service.name'], kind
| order by avg_delay desc

Run in Playground

Output

service.name kind avg_delay
checkoutservice server 45
cartservice client 30
frontend internal 12

This query calculates the average ingestion delay per service and kind to identify services affected by delayed ingestion.

Use ingestion_time to identify recently ingested suspicious activity, even if the event occurred earlier.

Query

['sample-http-logs']
| extend ingest_time = ingestion_time()
| where status == '401' and ingest_time > ago(1h)
| project _time, ingest_time, id, method, uri, ['geo.country']

Run in Playground

Output

_time ingest_time id method uri geo.country
2025-06-11T09:15:00Z 2025-06-11T10:45:00Z user123 GET /admin/login US
2025-06-11T08:50:00Z 2025-06-11T10:30:00Z user456 POST /api/session/start DE

This query surfaces failed login attempts that were ingested in the last hour, regardless of when the request actually occurred.

Other query languages#

Splunk SPL users

Splunk provides the _indextime field, which represents when an event was indexed. In APL, the equivalent concept is accessed using the ingestion_time function, which must be called explicitly.

Splunk example

... | eval ingest_time=_indextime

APL equivalent

...
| extend ingest_time = ingestion_time()
ANSI SQL users

ANSI SQL doesn’t have a standard equivalent to ingestion_time, since SQL databases typically don’t distinguish ingestion time from event time. APL provides ingestion_time for observability-specific workflows where the arrival time of data is important.

SQL example

SELECT event_time, CURRENT_TIMESTAMP AS ingest_time FROM logs;

APL equivalent

['sample-http-logs']
| extend ingest_time = ingestion_time()

Updated

Was this page helpful?