Event schema
Fields the query expects
| Field | Type | Why it exists |
|---|---|---|
| timestamp_utc | Timestamp | When the source says the event occurred. |
| received_at | Timestamp | When Telemetry received the event. |
| source | Utf8 | Producer or ingestion path. |
| event_name | Utf8 | Stable event contract name. |
Copy the query
SELECT
source,
event_name,
COUNT(*) AS events,
AVG(date_part('second', received_at - timestamp_utc)) / 60.0
AS average_delay_minutes,
approx_percentile_cont(
date_part('second', received_at - timestamp_utc) / 60.0,
0.95
) AS p95_delay_minutes,
SUM(CASE
WHEN received_at - timestamp_utc > INTERVAL '15 minutes' THEN 1
ELSE 0
END) AS events_over_15_minutes
FROM ingestion_events
WHERE received_at >= now() - INTERVAL '24 hours'
AND received_at >= timestamp_utc
GROUP BY source, event_name
HAVING COUNT(*) >= 20
ORDER BY p95_delay_minutes DESC;This read-only query is planned and executed against an empty typed table with Apache DataFusion 45.2.0. We review the synthetic sample output separately. Check field types, thresholds, and counting rules against your own data. Read the testing methodology.
Query result
p95 event delivery delay
Offline mobile synchronization is live but regularly delivers old events that can change recent product cohorts.
| source | event_name | events | average_delay_minutes | p95_delay_minutes | events_over_15_minutes |
|---|---|---|---|---|---|
| mobile_offline_sync | feature_used | 4,260 | 18.4 | 96.2 | 1,088 |
| billing_webhook | invoice_updated | 1,380 | 1.2 | 4.8 | 11 |
Synthetic example output. Run the query against your own event schema and thresholds before using it for operational decisions.
Reproduce the example
Download the sample data
The JSON bundle includes the event schema with field types, illustrative input rows, exact SQL, expected output, review notes, and engine version. The CSV contains the displayed result.
How the SQL works
- 1Receive time bounds the operational window, while event time measures how stale each delivered record is.
- 2Average and p95 delay separate a generally delayed producer from a long-tail problem.
- 3The explicit late-event count makes the impact legible without relying only on a percentile.
Edge cases to check
- Clock skew can produce negative or exaggerated delay; monitor and correct producer clocks separately.
- Offline clients may be expected to deliver late data and need a different threshold from server events.
- Decide whether dashboards restate recent buckets when late events arrive.
Recommended dashboard
- Bars: p95_delay_minutes by source
- Trend: late-event count by receive hour
- Table: newest late events with source and event time
Alert guidance
Alert only for sources with a documented delivery target and a minimum event count. Track expected offline synchronization on a dashboard.
Read alert setupSet up the events this query needs
Related instrumentation and guides
Continue the analysis
Count sensor deliveries and measurements separately
Run SQL on six fictional sensor deliveries. A network retry adds rows without adding measurements, changing a row-weighted average.
Open recipeMeasure event ingestion freshness
Find event sources that stopped delivering data or are arriving substantially later than they occurred.
Open recipeFind duplicate event ids
Identify event identifiers delivered more than once and measure whether duplicate handling is working.
Open recipeRun it on your events
Create a table, adapt the fields, and save the result
Start free, send structured events, and use the query result as a chart, shared dashboard widget, or alert input.