What is an ingestion delay?¶

An ingestion delay is the time between an event being created at source and a receiving platform accepting or processing it.

The delay may be a fraction of a second, several minutes or much longer.

Avoid this assumption: That a delayed event indicates deliberate interference or deletion. Usually, there are several ordinary technical explanations.

A collector may buffer records. A device may be offline. An API may impose rate limits. A network or destination platform may be unavailable. Large backlogs can also take time to process after service resumes.

Ingestion delay matters because it can alter the apparent sequence shown in a dashboard. Events that occurred at different times may arrive together. An older event may be displayed after a newer one.

The delay can be calculated only if both a reliable source timestamp and an ingestion timestamp are available. Even then, the source clock may be wrong, so the calculated figure may include clock offset as well as delivery delay.

Investigators should compare source time, collector time and ingestion time. Ask whether there were outages, queue backlogs, connector failures or maintenance during the relevant period.

Review collector health and retry records where timing is important. A sudden increase in delay across many sources may point to a central collection problem. Delay affecting one device may point to local connectivity or buffering.

Do not silently reorder events by ingestion time if the investigation concerns when the underlying activity occurred.

Operational takeaway¶

An ingestion delay measures the gap between source event creation and platform receipt, but that gap may reflect buffering, outages, processing backlogs and clock differences rather than suspicious activity.