ingestion_time

This page explains how to use the ingestion_time function in APL.

Use the ingestion_time function to retrieve the timestamp of when each record was ingested into Axiom. This function helps you distinguish between the original event time (as captured in the _time field) and the time the data was actually received by Axiom.

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.

For users of other query languages

If you come from other query languages, this section explains how to adjust your existing queries to achieve the same results in APL.

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

ANSI SQL users

ANSI SQL does not have a standard equivalent to ingestion_time, since SQL databases typically do not 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;

Usage

Syntax

ingestion_time()

Parameters

This function does not take any parameters.

Returns

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

Use case examples

Log analysis

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