> ## 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. # Core Events Firing, Mixpanel > Core Events Firing 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:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Event Health](/nerve-centre/connectors#connectors-by-type) ## At a glance > **Core Events Firing** is a live health check on the handful of events that matter most to your store, the ones your funnels, retention reports, and dashboards are built on. For each designated core event (for example View Product, Add to Cart, Begin Checkout, Purchase) the card shows whether it is still firing or has gone silent in the recent window. A core event dropping to zero is one of the most dangerous failures in product analytics, because it silently breaks every downstream report that depends on it, often without anyone noticing for days. This card turns that invisible failure into an immediate, obvious red status so you can fix the tracking before your numbers become unreliable. | | | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **What it counts** | The recent firing status of each event you have designated as core. Each core event is shown as firing (count above zero) or silent (count of zero) in the window. | | **Sample type** | Backend API data from Mixpanel event counts, evaluated per core event against the recent ingestion stream. | | **Why it matters** | A silent core event quietly corrupts funnels, retention, and dashboards downstream. Catching it fast prevents days of misleading data and missed revenue signals. | | **Reading the value** | Every core event should read as firing. Any event showing zero in the window is the alert, treat it as a tracking incident until you confirm otherwise. | | **Currency** | count | | **Time window** | `24h` | | **Alert trigger** | `any core event count = 0` | | **Sentiment key** | `mix_core_events_firing` | | **Roles** | owner, marketing | ## Calculation Vortex IQ checks the recent event counts for each event you have marked as core and compares each one against zero over the rolling 24-hour window. If every core event has fired at least once, the card reads healthy. If any single core event has a count of zero, the alert latches and that event is flagged as silent. The check is deliberately simple and binary, because for a core event that should fire many times a day, a count of zero is almost always a tracking break (a renamed event, a removed SDK call, a deploy regression) rather than a real absence of activity. ## Worked example *A representative reading of **Core Events Firing** for a typical merchant on Mixpanel.* Suppose you have designated four core events: View Product, Add to Cart, Begin Checkout, and Purchase. On a normal day each fires thousands of times, so all four show as firing and the card is green. On 14 Jun 26 a front-end deploy renames the Add to Cart event in the codebase but not in Mixpanel. Within the 24-hour window, Add to Cart drops to a count of zero while the other three keep firing. The alert latches, the card flags Add to Cart as silent, and you immediately know your cart and checkout funnels are about to look broken even though shoppers are still adding to cart normally. You restore the original event name, confirm counts resume, and the card returns to green. 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_alert_tracking_broken`](/nerve-centre/kpi-cards/mixpanel/event-tracking-broken-core-event-stopped-firing) | The dedicated alert for a core event that stopped firing, with incident detail. | | [`mix_event_volume`](/nerve-centre/kpi-cards/mixpanel/total-event-volume) | Total event volume confirms whether the problem is one event or the whole stream. | | [`mix_top_events`](/nerve-centre/kpi-cards/mixpanel/top-10-events-by-volume) | Shows the busiest events, so you can spot a core event missing from the leaderboard. | | [`mix_ingestion_lag`](/nerve-centre/kpi-cards/mixpanel/event-ingestion-lag) | Rules in or out ingestion delay as the reason an event looks silent. | | [`mix_health_score`](/nerve-centre/kpi-cards/mixpanel/mixpanel-tracking-health-score) | The overall tracking health roll-up that this card feeds into. | ## Reconciling against Mixpanel **Where to look in Mixpanel's own dashboard:** Open an Insights report, add each of your core events, and set the date range to the last 24 hours. Every core event should show a non-zero count. If one reads zero in Mixpanel too, the card is correct and you have a genuine tracking break. The Events page (the live event stream or the events lexicon) is also useful for confirming whether the event name still appears at all. **Why the Vortex IQ value may legitimately differ:** | Reason | Direction | What to do | | ------------------------------------------------------------------------------ | --------------------------------------------------- | ------------------------------------------------------------ | | **Ingestion lag.** Events queued on the SDK or in transit have not landed yet. | Vortex IQ may briefly read zero before data arrives | Check the ingestion-lag card, then re-check once lag clears. | | **Event renamed.** The event still fires under a new name. | Vortex IQ reads the old name as silent | Update the core event definition to the new name. | | **Time zone.** The 24h boundary differs from your reporting zone. | Marginal | Confirm both views use the same project time zone. | **Cross-connector reconciliation:** if a core purchase event reads silent, cross-check order counts in your ecommerce platform, real orders with no Purchase events confirms a tracking break rather than a sales drop. For divergence investigations, use Vortex Mind. ## Known limitations / merchant FAQs **Q: How often does Core Events Firing update?** It is evaluated on the rolling 24-hour window and refreshes frequently, so a core event going silent can surface within minutes to hours of the data arriving. Ingestion lag on the SDK side can delay detection slightly. **Q: A low-traffic core event sometimes reads zero overnight. Is that a real problem?** For genuinely low-volume events, a quiet overnight window can produce a legitimate zero. That is why core events should be the high-frequency ones that always fire. If you must track a rarer event, consider whether it belongs in the core set or should be watched with a different card. **Q: The card is red but my sales look fine. What now?** That is the classic tracking-break signature, orders are landing but the event that records them stopped firing. Check the event name in your latest deploy and the ingestion-lag card. Your data, not your store, is the thing that is broken. **Q: Can I customise the alert threshold?** Yes, which events count as core and the evaluation window are configurable per profile in the Sensitivity tab. Add or remove events from the core set as your funnel evolves, and widen the window for stores with lower overnight traffic. *** ### Tracked live in Vortex IQ Nerve Centre *Core Events Firing* 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.