At a glance
Event Ingestion Lag measures the delay between when an event happened on the client and when Mixpanel actually received it. A small lag is normal, since SDKs batch events and flush them in groups, but a growing lag is an early sign of trouble: a misconfigured flush interval, a flaky network on mobile, or backpressure in your ingestion pipeline. When lag climbs, your most recent reports look thin until the backlog catches up, which can make a healthy store look like it is in decline. Watching lag separates real behaviour changes from data simply arriving late.
| What it counts | The delay between an event’s client-side timestamp and the time Mixpanel ingested it, expressed as a duration. |
| Sample type | Backend API data from Mixpanel, comparing event timestamps against ingestion timing in real time. |
| Why it matters | Late events make recent windows look low even when nothing is wrong. High lag also points to SDK or pipeline faults that need fixing before they cost you data. |
| Reading the value | The card shows a current lag duration. A few seconds to a couple of minutes is usually normal; a reading climbing past an hour means events are stacking up behind a flush or pipeline problem. |
| Currency | count |
| Time window | RT |
| Alert trigger | >1h |
| Sentiment key | mix_ingestion_lag |
| Roles | owner, marketing |
Calculation
Vortex IQ tracks the gap between the client-side timestamp carried on each Mixpanel event and the time that event was ingested, and surfaces this as a current lag duration. Because mobile and browser SDKs batch events and flush them on an interval, a small steady lag is expected and not a fault. The card watches for the gap growing beyond a normal range; the alert latches when lag crosses the configured threshold of one hour, which typically signals an SDK flush misconfiguration, a network or device problem on the client, or backpressure somewhere in the ingestion path. The value is read in real time so a developing backlog surfaces quickly.Worked example
A representative reading of Event Ingestion Lag for a typical merchant on Mixpanel. Imagine your store normally runs an ingestion lag of around 30 seconds, mostly the SDK’s batching interval. On 14 Jun 26 a mobile app update ships that raises the flush interval and adds an offline queue. Over the next hour the lag climbs past 90 minutes as events from the app stack up before flushing in large bursts. The alert fires and your recent DAU and event-volume windows look low even though usage is normal. You open the siblings, see total volume dip and then catch up in bursts, and trace it to the new flush setting in the app release. For deeper investigation, use Vortex Mind to trace upstream causes; for natural-language exploration, ask Ask Viq.Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
mix_core_events_firing | Confirms whether core events are genuinely silent or just arriving late behind a lag spike. |
mix_event_volume | Shows the volume dip and later catch-up that high lag produces in recent windows. |
mix_health_score | Rolls lag into the overall tracking score, so a lag spike usually drags the score down. |
mix_alert_tracking_broken | Helps you tell a real stoppage from events that are simply delayed. |
mix_top_events | Reveals which high-volume events thinned out while the backlog cleared. |
Reconciling against Mixpanel
Where to look in Mixpanel’s own dashboard: Mixpanel’s data-management and ingestion views report on event arrival and timing, and you can sanity-check the effect of lag by building an Insights report on total event volume for the most recent hours. If lag is high, the newest buckets will look low and then fill in as the backlog flushes. Comparing the freshest window to one a few hours old shows whether recent data is simply incomplete rather than genuinely down. Why the Vortex IQ value may legitimately differ:| Reason | Direction | What to do |
|---|---|---|
| SDK batching interval. A longer flush interval naturally raises baseline lag. | Lag reads higher by design | Compare against your configured flush interval before treating it as a fault. |
| Client clock skew. A wrong device clock distorts the client timestamp and the measured gap. | Variable | Spot-check a few profiles in Mixpanel for implausible timestamps. |
| Backfill and historical imports. Bulk imports carry old client timestamps. | Lag reads very high transiently | Exclude known import jobs when reading the live value. |