What is an ingestion timestamp?¶

An ingestion timestamp records when a receiving platform accepted or processed an event.

It is different from the event timestamp, which is intended to record when the source system says the activity occurred.

Avoid this assumption: That the most visible timestamp on a dashboard is always the time of the underlying event. It may be the ingestion time instead.

For example, a laptop may create an event at 09:00 while offline. When it reconnects at 12:00, the collector forwards the record and the platform ingests it at 12:03. Both times may be correct, but they describe different stages.

Ingestion timestamps are useful. They can identify collection delay, show when data became available to analysts and help diagnose outages or backlogs.

But they can distort sequence if used incorrectly. Several older events may arrive together and appear simultaneous. Events from different sources may have different collection delays. Sorting only by ingestion time can therefore produce a false narrative.

Investigators should establish which timestamp each field represents. Ask whether the dashboard displays source time, ingestion time, processing time or a converted local time.

Preserve the original timestamp fields and their time-zone information. Where a central platform has reformatted them, compare with the raw event.

If the source clock was wrong, ingestion time may provide a useful external reference, but it does not automatically correct the source time. The delay between the two must be understood.

Operational takeaway¶

An ingestion timestamp shows when a platform received or processed an event, so it can explain collection delay but should not be substituted automatically for the time of the underlying activity.