> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Event Ingestion Lag, Mixpanel > Event Ingestion Lag for Mixpanel stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Card class:** [Non-Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Event Health](/nerve-centre/connectors#connectors-by-type) ## 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`](/nerve-centre/kpi-cards/mixpanel/core-events-firing) | Confirms whether core events are genuinely silent or just arriving late behind a lag spike. | | [`mix_event_volume`](/nerve-centre/kpi-cards/mixpanel/total-event-volume) | Shows the volume dip and later catch-up that high lag produces in recent windows. | | [`mix_health_score`](/nerve-centre/kpi-cards/mixpanel/mixpanel-tracking-health-score) | Rolls lag into the overall tracking score, so a lag spike usually drags the score down. | | [`mix_alert_tracking_broken`](/nerve-centre/kpi-cards/mixpanel/event-tracking-broken-core-event-stopped-firing) | Helps you tell a real stoppage from events that are simply delayed. | | [`mix_top_events`](/nerve-centre/kpi-cards/mixpanel/top-10-events-by-volume) | 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. | **Cross-connector reconciliation:** if recent Mixpanel windows look thin but your ecommerce platform reports normal real-time activity, ingestion lag is the likely cause rather than a real drop in demand. For divergence investigations, use Vortex Mind. ## Known limitations / merchant FAQs **Q: How often does Event Ingestion Lag update?** It is read in real time, so a developing backlog surfaces within minutes. A small steady lag from SDK batching is normal and not a cause for concern. **Q: My lag is high but events are still arriving. Is data lost?** Usually not. High lag normally means events are delayed, not dropped; they tend to flush in bursts once the queue clears. The risk is misreading a thin recent window as a real decline before the backlog catches up. **Q: Why does the most recent hour always look a little low?** The freshest window almost always understates volume because the latest batch has not flushed yet. This is expected; let the SDK flush interval pass before judging the newest data. **Q: Can I customise the alert threshold?** Yes, the one-hour lag threshold is configurable per profile in the Sensitivity tab. Stores with longer flush intervals or heavy mobile traffic can loosen it, while real-time-sensitive stores can tighten it. *** ### Tracked live in Vortex IQ Nerve Centre *Event Ingestion Lag* is one of hundreds of KPI pulses Vortex IQ tracks across Mixpanel and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.