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 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.
...
| extend ingest_time = ingestion_time()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.
['sample-http-logs']
| extend ingest_time = ingestion_time()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, statusOutput
| _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 descOutput
| 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']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.