Mixpanel driftsforstyrrelser

1. 26. august 2026 kl. 21.39 UTCinvestigating

   Mixpanel oplever forringet Query API ydeevne, hvilket resulterer i HTTP 500 svar, når du spørger rapporter til projekter med US Data Residency. Projekter med EU og IN Data Residency forbliver uberørt. Vi sætter pris på din tålmodighed, mens vores ingeniører arbejder på at genoprette normal funktionalitet. Vi vil sende statusopdateringer på vores statusside. Hvis du har spørgsmål, bedes du kontakte support.

2. 26. august 2026 kl. 22.11 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 26. august 2026 kl. 22.28 UTCmonitoring

   En rettelse er blevet implementeret, og vi ser forbedrede succesrater for Query API. Vi vil fortsat overvåge for at sikre stabilitet.

4. 26. august 2026 kl. 22.45 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 19. august 2026 kl. 23.20 UTCidentified

   Vi oplever i øjeblikket problemer med at befolke begivenhedsegenskaber i dropdown menuer. Vi sætter pris på din tålmodighed, mens vores ingeniører arbejder på at genoprette funktionalitet. Hvis du har spørgsmål, bedes du kontakte support @ mixpanel.com

2. 20. august 2026 kl. 01.04 UTCidentified

   Vi fortsætter med at arbejde på en løsning på dette problem.

3. 20. august 2026 kl. 02.52 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

4. 20. august 2026 kl. 03.05 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. august 2026 kl. 07.19 UTCinvestigating

   We are aware that the Get-Report tool in the Mixpanel MCP server is currently failing when called with skip_results: false. Report metadata is unaffected. We are investigating the issue and will provide updates as we have them.

2. 6. august 2026 kl. 08.39 UTCidentified

   The issue has been identified and fix is being implemented.

3. 6. august 2026 kl. 09.12 UTCmonitoring

   A fix has been deployed and we're now monitoring the results. Report queries in the Mixpanel MCP server should be functioning normally. We'll continue to watch closely and provide a final update once we've confirmed full resolution.

4. 6. august 2026 kl. 13.32 UTCresolved

   This incident has been resolved.

1. 22. juli 2026 kl. 08.03 UTCinvestigating

   Vi oplever i øjeblikket problemer med Mixpanel agenten i webappen. Vores ingeniørhold er blevet advaret og undersøger problemet og arbejder på at genoprette dets funktionalitet. Vi sætter pris på Deres tålmodighed, når vi arbejder på at løse dette problem. Hvis du har spørgsmål, bedes du kontakte support.

2. 22. juli 2026 kl. 09.52 UTCinvestigating

   teamet fortsætter med at undersøge spørgsmålet og næste skridt. Tak for din tålmodighed.

3. 22. juli 2026 kl. 10.55 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

4. 22. juli 2026 kl. 14.47 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 11. juli 2026 kl. 07.53 UTCinvestigating

   Vi oplever i øjeblikket forsinkelser i vores data indtagelse rørledning, som påvirker realtidsdata for projekter, der er indskrevet i de amerikanske projekter, hvilket resulterer i forsinkelser for en delmængde af projekter. Mens ingen data går tabt, undersøger vores ingeniørhold aktivt sagen og arbejder på at genoprette realtidsfunktionalitet så hurtigt som muligt. Vi sætter pris på din tålmodighed i denne tid. Hvis du har spørgsmål, bedes du kontakte support.

2. 11. juli 2026 kl. 09.17 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål.

3. 11. juli 2026 kl. 10.15 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

4. 11. juli 2026 kl. 12.54 UTCidentified

   Vi fortsætter med at arbejde på en løsning på dette problem.

5. 11. juli 2026 kl. 14.25 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

6. 11. juli 2026 kl. 15.54 UTCresolved

   Denne hændelse er blevet løst.

7. 16. juli 2026 kl. 23.47 UTCpostmortem

   # Summary Mellem ca. * * 11: 35 PM PT den 10. juli og 7: 19 AM PT den 11. juli 2026 * *, data indtagelse for Mixpanel projekter i den amerikanske region løb bagud med op til ~ 2 timer. I dette vindue, rapporter og dashboards midlertidigt viste ufuldstændige data - seneste tidsintervaller kunne vises som skarpe, kunstige dråber i målinger såsom aktive brugere eller indtægter. * * Ingen data gik tabt. * * Alle begivenheder blev i kø permanent og behandles i fuld, når backloggen ryddet; målinger returneres til nøjagtige værdier på egen hånd, uden at kunden handling kræves. Årsagen opstod i vores indtagelse kontrol: for et lille antal meget højt volumen projekter, den indtagelse, vi tillod, havde drevet ud af tilpasning med kapaciteten til disse projekter. Stor historisk import - helt legitimt brug af platformen - blev derfor indrømmet hurtigere, end deres infrastruktur kunne absorbere, og to egenskaber ved vores rørledning vendte den lokale overbelastning til en regional-bred forsinkelse. Nedenstående rettelser reign disse kontroller, således at enhver import, af enhver størrelse, automatisk holdes inden for sikre grænser. Hvad skete der? Mixpanel "s indtagelse rørledning er skægget og multi-lejer: hvert projekt data er fordelt på et sæt af partitioner størrelse for sin forventede volumen, og for gennemløb, er begivenheder fra mange kunder behandles sammen i partier. Dette design giver høj effektivitet, men det afhænger af en invariant: den hastighed, hvormed vi indrømmer et projekts trafik skal matche den kapacitet, der er afsat til det. Når denne invariant holder, selv meget stor import absorberes problemfrit. Her holdt den ikke. Et lille antal meget store historiske data import kørte på projekter, hvis tilladte indtagelse var med tiden vokset langt ud over deres hensatte fordelingskapacitet. Den overskydende volumen koncentreret på specifikke partitioner som * * hot spots * *, mætte den del af streaming flåde tjener dem. To faktorer så udvidet virkningen: * * * Bundet, multi-lejer forarbejdning forstærket hot spots. * * Fordi begivenheder fra mange kunder rejser sammen i partier, langsommelighed og fejl på de overbelastede partitioner forsinkede uafhængige kunders arrangementer, der delte disse partier. * * * Automatisk scene- up var ineffektiv. * * Tilføjelse af kapacitet kan ikke opløse et hot spot af denne art, fordi de overbelastede partitioner forbliver fastgjort til samme infrastruktur, og en kapacitetsgrænse i en komponent af vores streaming infrastruktur forhindrede den ekstra kapacitet i at få virkning. Sammen blev det, der skulle have været en kort, selvhelbredende afmatning, til en forsinkelse på flere timer, der krævede manuel indgriben. # Timeline\ (Pacific Time, Juli 10-11\) * * * 11: 35 PM * * - Automatiseret alarmering opdaget indtagelse backlog; on- call ingeniør aktiveret med det samme. * * 12: 49 AM * * - Status side hændelse bogført; indslag scoped til den amerikanske region kun. * * * 1: 23 AM * * - Den største bidragende import blev sat på pause. * * 1: 55- 6: 48 AM * * - Progressive lempelser: yderligere trafikkilder væltet, visse backloged data udskudt med ejerens aftale, svigt isolation aktiveret i rørledningen, og berørte infrastrukturknudepunkter erstattet. * * 7: 19 AM * * - Backlog fuldt behandlet; alle projekter aktuelle. Status side flyttet til overvågning, derefter løst efter en stabil observationsperiode. "Root cause 1. * * Indtagningshastighed grænser forkert tilpasset den reserverede kapacitet. * * For de drivende projekter, de satser vores platform indrømmede var vokset ud af trit med den infrastruktur, der er afsat til dem, så legitime høj-volumen import blev lukket ind hurtigere, end deres partitioner kunne absorbere. Dette er den systemiske rod årsag. Selve importen var en legitim anvendelse af platformen. 2. * * Bundet, multi-lejer forarbejdning forstærket overbelastning. * * Fejl på de overbelastede partitioner forsinkede uafhængige kunders arrangementer, der deler de samme behandlingsbatcher, og spredte et lokaliseret problem på tværs af platformen. 3. * * Trafik til de overbelastede partitioner kunne ikke omfordeles. * * Partition- to- server opgave i streaming-laget var ikke load- opmærksomme, så hot spots forblev fastgjort til de samme servere uanset flådens størrelse - den samlede kapacitet var tilstrækkelig, men det kunne ikke bringes til at bære. En skalering grænse i en komponent af vores streaming infrastruktur yderligere dette ved at forhindre scale-up fra at tilføje kapacitet, som forsinkede diagnosen indtil ingeniører greb manuelt ind. "What we 're changing Den endelige tilstand, vi bygger mod: * * hvert projekt "s indtagelse grænser automatisk matche sin provied kapacitet, således at import af enhver størrelse, herunder fuld historiske backfills og data lagersyncs, kan køre uden forudgående koordinering, og et projekts volumen er forhindret i at påvirke en andens data friskhed. * *. Allerede indsat - forbedre vores indtagelse håndtering: * * * Forbedret håndtering af hotspot. * * Trafikfordelingen i streaming-laget er nu belastet-bevidst, spredning af koncentreret belastning mere jævnt over hele flåden, og enkelte problempunkter er nu genafprøvet separat i stedet for at holde op resten af deres parti - reducere, men ikke eliminere, den indvirkning en lokaliseret overbelastning kan have på ikke-relateret trafik. * * * Udlejning af de højeste arbejdsbelastninger * * til infrastruktur af passende størrelse, prioriteret efter risiko. Allerede indsat - ændre hvordan vi driver tredje part streaming service: * * * Revideret og reafstemt flådens kapacitetsprofil * * så individuelle servere har betydeligt mere headroom for koncentreret belastning, og arbejdede med udbyderen for at løse skalering begrænsning stødt under hændelsen. I øjeblikket: * * * Kapacitets- bevidst hastighedsbegrænsning * * - at lukke hullerne mellem individuelt tildelte projektgrænser og hvert projekts reelle udbudskapacitet, udvide hastighedsbegrænsning til indsugningsveje, der tidligere manglede det, og forbinde eventuelle fremtidige grænser stigning til en kapacitetsstigning, som er designet til at forhindre denne klasse af misorientering fra tilbagevendende.. * * * Finer- graden volumen overvågning og advarsel * * så kapacitet fejljustering detekteres og rettes, før det kan påvirke nogen kunde. * Vurdering af stærkere arbejdsbyrde isolation / tilbage-log opsving prioritering for bulk / backfill trafikveje, så historisk import har reduceret indvirkning på levende trafik "Common questions * * * blev nogen data tabt? * * Nej. Begivenheder blev varigt i kø under hele hændelsen og blev fuldt behandlet, når backlog ryddet. Eventuelle metriske dråber set under vinduet var et display artefakt af forsinkelsen og selvkorrigeret. * * * Skal jeg koordinere stor import eller backfills med Mixpanel? * * Nej. Vores mål er, at platformen til at holde enhver import inden for sikre priser automatisk, så backfills og lagersyncs kan køre uden planlægning eller varsel. Vi er stadig ved at udrulle den kapacitet-bevidste kontrol, der leverer dette. I mellemtiden, hvis du planlægger en usædvanlig stor import eller backfill, anbefaler vi koordinering med din konto team, så vi kan bekræfte kapacitet på forhånd. * * * Hvordan forhindrer det fremskridt? * * Den systemiske fix er at stramme hullerne mellem individuelt tildelte projektrater og hvert projekts reelle udbudskapacitet, og udvide hastigheden begrænser sig til de indsugningsveje, der tidligere manglede det - så overbelastning af denne type er stoppet ved optagelse. Desuden er den begrænsning, som forlængede hændelsen, der er fastsat, rørledningen nu relancere individuelle problempunkter separat, så en lokaliseret overbelastning har langt mindre indvirkning på ikke-relateret trafik, og bulk trafik er yderligere isoleret fra levende trafik. * * * Kan individuelle projekter prioriteres under opsvinget? * * Denne kapacitet eksisterede ikke under hændelsen - alle projekter inddrives med samme hastighed. Vi er i færd med at evaluere prioriteringsmekanismerne for tilbagesøgning som en del af vores opfølgningsarbejde. Vi undskylder forstyrrelsen og den bekymring, de midlertidigt deprimerede målinger forårsagede. Kontakt venligst din konto eller support med spørgsmål.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 29. juni 2026 kl. 19.47 UTCinvestigating

   Mixpanel oplever forringet ydeevne med vores Query API, herunder øget latency. Du kan se langsom-loading rapporter eller forespørgsel fejl. Vi sætter pris på din tålmodighed, mens vores ingeniører arbejder på at genoprette normal funktionalitet. Vi vil sende statusopdateringer på vores statusside. Hvis du har spørgsmål, bedes du kontakte support.

2. 29. juni 2026 kl. 21.04 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 29. juni 2026 kl. 22.42 UTCidentified

   Query latency har stabiliseret sig, selvom vores team fortsætter med at undersøge den underliggende årsag til den forringede ydeevne. Vi vil fortsætte med at sende opdateringer som vores undersøgelse skrider frem. Tak for din tålmodighed.

4. 30. juni 2026 kl. 02.15 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

5. 30. juni 2026 kl. 03.30 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 3. juni 2026 kl. 20.05 UTCinvestigating

   Mixpanel is currently experiencing a disruption in the ability to invite and delete internal users within organizations. We appreciate your patience while our engineers work to restore this functionality. If you have any questions, please contact [email protected]

2. 3. juni 2026 kl. 20.17 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 3. juni 2026 kl. 21.27 UTCresolved

   This incident has been resolved.

1. 2. juni 2026 kl. 11.02 UTCinvestigating

   We are experiencing delays with our data ingestion and shuffling pipeline to projects with all projects. No data is being lost but as a result, real-time data is delayed. We appreciate your patience while our engineers work to restore real-time functionality. If you have any questions, please contact support

2. 2. juni 2026 kl. 12.31 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 2. juni 2026 kl. 14.31 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 2. juni 2026 kl. 16.53 UTCresolved

   This incident has been resolved.

1. 1. juni 2026 kl. 14.15 UTCinvestigating

   We are experiencing delays with our data ingestion and shuffling pipeline to projects with US & India data residency. No data is being lost but as a result, real-time data is delayed. We appreciate your patience while our engineers work to restore real-time functionality. If you have any questions, please contact support

2. 1. juni 2026 kl. 15.08 UTCinvestigating

   We have now identified an ingestion delay for EU projects, and are continuing to investigate the issue. Thank you for your patience.

3. 1. juni 2026 kl. 15.29 UTCidentified

   The issue has been identified, and a fix is being implemented.

4. 1. juni 2026 kl. 16.38 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

5. 1. juni 2026 kl. 19.42 UTCresolved

   This incident has been resolved.

1. 19. maj 2026 kl. 19.03 UTCinvestigating

   A subset of users are currently facing issues accessing boards that they previously had access to view. Our Engineering team is actively investigating and will update shortly.

2. 19. maj 2026 kl. 19.10 UTCidentified

   The issues has been identified and a fix is being implemented. As a workaround boards can be explicitly shared with users who are having issues viewing them currently.

3. 19. maj 2026 kl. 20.23 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 19. maj 2026 kl. 21.18 UTCresolved

   This incident has been resolved.

1. 14. maj 2026 kl. 23.17 UTCinvestigating

   We are experiencing degraded performance with our Query API, including increased latency. You may see slow-loading reports, incomplete query results, query errors, or data discrepancies. We appreciate your patience while our engineers work to restore normal functionality. We will post progress updates on our status page. If you have any questions, please contact support.

2. 14. maj 2026 kl. 23.48 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 15. maj 2026 kl. 10.19 UTCidentified

   We are continuing to work on a fix for this issue.

4. 15. maj 2026 kl. 12.28 UTCidentified

   We've continued to make progress on the issue affecting some US projects. Query success rates have returned to normal levels, and the related processing delays have also recovered. A subset of affected projects may still see incomplete data in query results while our recovery process runs. We're actively working on this and will share another update in 2 hours. Impact remains limited to our US region. We do not currently believe any data has been permanently lost.

5. 15. maj 2026 kl. 14.31 UTCidentified

   Recovery is progressing well. Query success rates remain at normal levels, and missing data has now been restored for a portion of affected projects. We're continuing the recovery process for the remaining affected projects and currently estimate full recovery within approximately 3–5 hours. Some customers may still see incomplete data in query results until this work is complete.

6. 15. maj 2026 kl. 16.37 UTCidentified

   We are continuing to work on resolving this issue. Our current estimate for full recovery is approximately 3–5 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

7. 15. maj 2026 kl. 18.47 UTCidentified

   Recovery is continuing to progress and query latency has returned to normal levels. Our current estimate for full recovery is approximately 3–4 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

8. 15. maj 2026 kl. 19.56 UTCidentified

   We are investigating an increase in query latency that appears to be unrelated to the ongoing recovery. You may experience slower-loading reports. Our team is actively looking into the cause and we will provide an update shortly. Recovery is continuing to progress. Our current estimate for full recovery is approximately 3–4 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

9. 15. maj 2026 kl. 21.23 UTCidentified

   Query latency has returned to normal levels. We are continuing to monitor.

10. 15. maj 2026 kl. 22.14 UTCidentified

    Query latency has returned to normal levels and has been resolved. Recovery is continuing to progress, and our current estimate for full recovery is approximately 4–5 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

11. 16. maj 2026 kl. 00.17 UTCidentified

    Recovery is continuing to progress. Our current estimate for full recovery is approximately 1-2 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

12. 16. maj 2026 kl. 01.52 UTCmonitoring

    A fix has been implemented and we are monitoring the results.

13. 16. maj 2026 kl. 02.50 UTCresolved

    This incident has been resolved.

14. 21. maj 2026 kl. 21.43 UTCpostmortem

    # Mixpanel RCA: Transient Data Access Issue, May 14, 2026 ## Summary On Thursday, May 14, 2026 at approximately 2:30 PM PT, a routine but infrequent cleanup operation in Mixpanel's storage system mistakenly removed a portion of production data files in addition to the unused files it was intended to remove. Some customers experienced query errors during the hours that followed. We detected the issue within minutes, deployed mitigations the same evening that returned query success rates and latency to normal, and restored the affected files from backup by 5:15 PM PT on Friday, May 15. Mixpanel's ingestion pipeline was not affected and no event data was lost in transit. ## What happened This incident was triggered by a storage cleanup procedure that runs periodically to remove files no longer referenced by Mixpanel's metadata. The procedure was more involved than usual: it followed a recent enhancement to our file storage strategy that left a set of unused files behind in our storage backend, and addressing them required extending our standard cleanup approach to cover a new code path. As part of executing this extended cleanup, an engineer generated the list of files to delete using a SQL query whose date filter was not strictly earlier than the reference snapshot it was being compared against. As a result, a small set of legitimate production files that had been written in the gap window between the snapshot and the filter date were incorrectly classified as unused and removed. The deletion ran for roughly half an hour before internal alerting caught the resulting query failures and the operation was stopped. The trigger was operator error against an ambiguous runbook, not a defect in the live serving path or in our ingestion pipeline. ## Customer impact Impact unfolded in two phases. The first phase ran from Thursday at approximately 2:30 PM PT until 8:11 PM PT — roughly five and a half hours. During this window, customers across the platform may have seen slower or failed queries when their requests touched files that had been deleted. The breadth and severity varied by project depending on which data each query touched. By 8:11 PM PT, mitigations had fully rolled out — queries automatically retried against an alternate availability zone, and a fallback path was put in place to serve missing files from a backup datastore. After this point, query success rate and latency returned to normal. The second phase lasted from 8:11 PM PT Thursday through approximately 5:15 PM PT Friday, May 15. During this window, fewer than 2% of customers were still affected — specifically, those whose deleted files had not yet been fully restored from backup. The vast majority of these files were recovered by Friday afternoon. A small number of projects \(under 30\) had files that could not be fully recovered from backup, and we are following up with those accounts directly. ## Timeline \(Pacific Time\) * May 14, 2:30 PM — Cleanup operation begins * May 14, 3:11 PM — Internal alerting flags query failures; the cleanup operation is stopped within minutes * May 14, 4:07 PM — Status page banner posted * May 14, 4:45 PM — Mitigation deployed: queries automatically retry against an alternate availability zone * May 14, 7:12 PM — Mitigation deployed: queries fall back to a backup datastore for missing files * May 14, 8:11 PM — Query success rate and latency fully restored to normal levels * May 15, 5:15 PM — File restore from backup complete; status page banner resolved ## Why this happened Several contributing factors lined up. The runbook for this cleanup procedure had ambiguous wording around the ordering and timing of its inputs. It had been recently authored to handle the new file-storage code path and had not gone through a formal review before being used. Our cleanup tooling did not programmatically enforce the safety invariant that the date filter must be strictly before the reference snapshot. That invariant lived only in operator-authored SQL. The extended cleanup was being executed in parallel across two storage layers by two different engineers, which increased the room for error. ## What we're doing to prevent recurrence We have already made or have actively in flight the following changes. We are adding programmatic safeguards to our cleanup tooling so that an input set whose date filter is not safely before the reference snapshot is rejected before any deletion occurs, along with a reconciliation step that flags any production-referenced file before deletion proceeds. Destructive cleanup operations will now run in phased stages, starting with internal projects and pausing for a holding period before any broader execution. Destructive storage operations now require a second engineer to sign off on the exact deletion set and to be present during execution, matching the practice we already follow for database migrations. We have updated the cleanup runbook with explicit guidance on input timing, required safety buffers, and an enforced review process for any runbook covering a destructive operation. Longer term, we are working to eliminate the manual portion of this cleanup procedure entirely and route it through our existing automated cleanup infrastructure, so the class of failure that produced this incident is no longer reachable through human input. ## Closing Reliability and data integrity are foundational to the trust our customers place in Mixpanel, and we recognize the impact this incident had on the teams who rely on us. We are sorry for the disruption. If you have questions about how this incident may have affected a specific project, please reach out to your account team or Mixpanel Support.

1. 13. maj 2026 kl. 16.34 UTCidentified

   Data Volume Monitoring is again experiencing degraded performance due to a recurring upstream provider disruption. We're mitigating now.

2. 13. maj 2026 kl. 21.40 UTCidentified

   We are continuing to work on a fix for this issue.

3. 14. maj 2026 kl. 13.35 UTCresolved

   This incident has been resolved.

1. 12. maj 2026 kl. 17.45 UTCinvestigating

   We are currently investigating an issue that leads to degraded performance of Data Volume Monitoring in a subset of US-based projects. We truly appreciate your patience and apologize for the inconvenience. If you have any questions, please contact support (https://mixpanel.com/get-support).

2. 12. maj 2026 kl. 17.46 UTCidentified

   An upstream service provider outage is causing this issue. We are deploying a fix to mitigate the disruption.

3. 12. maj 2026 kl. 20.24 UTCmonitoring

   A fix has been implemented, and we are monitoring the result.

4. 12. maj 2026 kl. 21.44 UTCresolved

   This incident has been resolved.

1. 6. maj 2026 kl. 00.00 UTCinvestigating

   A subset of projects are experiencing issues exporting data to the Snowflake warehouse via Mixpanel pipelines. We are currently investigating this issue.

2. 6. maj 2026 kl. 09.32 UTCidentified

   We have identified the issue affecting Snowflake pipeline exports for a subset of projects, and our engineering team is working on a resolution.

3. 6. maj 2026 kl. 20.04 UTCresolved

   This incident has been resolved.

1. 9. april 2026 kl. 20.03 UTCidentified

   We are currently experiencing an interruption with our credit card processing. Our engineers have identified the issue and are working on a fix.

2. 9. april 2026 kl. 21.00 UTCmonitoring

   A fix has been deployed, and all impacted accounts have had their billing re-run. If you continue to receive errors, please ensure the card on file is up to date. If you are still experiencing issues, please submit a support ticket.

3. 9. april 2026 kl. 21.44 UTCresolved

   This incident has been resolved.

1. 16. marts 2026 kl. 16.50 UTCidentified

   Mixpanel is experiencing increased query latency for projects with EU residency, which may result in HTTP 500 responses when querying or saving reports. Projects with US and IN residency remain unaffected. Our engineering team is working on a resolution.

2. 16. marts 2026 kl. 19.29 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 16. marts 2026 kl. 21.47 UTCresolved

   This incident has been resolved.

1. 2. marts 2026 kl. 21.00 UTCinvestigating

   We are currently experiencing issues with loading Mixpanel.com and are working to restore service as quickly as possible. Our team is investigating the issue and will provide updates as soon as we have more information. Thank you for your patience.

2. 2. marts 2026 kl. 21.09 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 2. marts 2026 kl. 21.09 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 2. marts 2026 kl. 21.53 UTCresolved

   This incident has been resolved. If Mixpanel is still not loading, please clear your cache and cookies.

1. 2. marts 2026 kl. 19.48 UTCinvestigating

   A subset of users are experiencing OAuth issues when connecting to our MCP server. We are currently investigating this issue.

2. 2. marts 2026 kl. 19.49 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 2. marts 2026 kl. 19.50 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 2. marts 2026 kl. 20.08 UTCmonitoring

   We have partially mitigated the issue and are continuing to monitor for any further impact. We are also actively working to address the root cause.

5. 3. marts 2026 kl. 01.43 UTCresolved

   This incident has been resolved.

1. 2. marts 2026 kl. 18.41 UTCinvestigating

   A subset of users are experiencing OAuth issues when connecting to our MCP server. We are currently investigating this issue.

2. 2. marts 2026 kl. 18.44 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 2. marts 2026 kl. 18.45 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 2. marts 2026 kl. 18.53 UTCresolved

   This incident is resolved.

1. 30. januar 2026 kl. 18.39 UTCinvestigating

   We are currently experiencing delays with Cohort Syncs to external destinations, including custom webhooks and engagement platforms. Our team is investigating the issue and actively working on a resolution. We sincerely apologize for the inconvenience and thank you for your kind understanding. If you have any questions, please contact support

2. 30. januar 2026 kl. 20.05 UTCmonitoring

   A fix has been implemented, and we are monitoring the results. Recurring cohort syncs should resume on the next scheduled run with no additional action required.

3. 30. januar 2026 kl. 22.14 UTCmonitoring

   We are continuing to monitor for further issues. We have identified that a subset of Cohort Syncs are still experiencing delays and are working to resolve these remaining cases.

4. 31. januar 2026 kl. 01.48 UTCmonitoring

   Additional fixes have been implemented. We are continuing to monitor for any further issues.

5. 31. januar 2026 kl. 02.41 UTCresolved

   This incident has been resolved.