Mixpanel kesinti geçmişi

1. 26 Ağustos 2026 21:39 UTCinvestigating

   Mixpanel, ABD Data Residency ile projeler için raporlar sorgularken HTTP 500 yanıtını deneyimliyor. AB ve IN Data Residency ile projeler etkilenmez. Mühendislerimiz normal işlevselliği geri yüklemek için çalışırken sabrınızı takdir ediyoruz. Durum sayfamızda ilerleme güncellemelerini yayınlayacağız. Herhangi bir sorunuz varsa lütfen iletişim desteği ile iletişime geçin.

2. 26 Ağustos 2026 22:11 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

3. 26 Ağustos 2026 22:28 UTCmonitoring

   Bir düzeltme uygulandı ve Sorgu API için gelişmiş başarı oranları görüyoruz. istikrar sağlamak için izlemeye devam edeceğiz.

4. 26 Ağustos 2026 22:45 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 19 Ağustos 2026 23:20 UTCidentified

   Şu anda aşağı menülerde olay özellikleri ile ilgili sorunlar yaşıyoruz. Sabrınızı takdir ederiz, mühendisler işlevsellik geri yüklemek için çalışırken. Herhangi bir sorunuz varsa lütfen [email protected] ile iletişime geçin

2. 20 Ağustos 2026 01:04 UTCidentified

   Bu sorun için bir düzeltme üzerinde çalışmaya devam ediyoruz.

3. 20 Ağustos 2026 02:52 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

4. 20 Ağustos 2026 03:05 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 6 Ağustos 2026 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 Ağustos 2026 08:39 UTCidentified

   The issue has been identified and fix is being implemented.

3. 6 Ağustos 2026 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 Ağustos 2026 13:32 UTCresolved

   This incident has been resolved.

1. 22 Temmuz 2026 08:03 UTCinvestigating

   Şu anda webapp içinde Mix Panel ajanı ile ilgili sorunlar yaşıyoruz. Mühendislik ekibimiz uyarılandı ve sorunu araştırıyor ve işlevselliğini geri yüklemek için çalışıyor. Bu konuyu çözmek için çalıştığımız gibi sabrınızı takdir ediyoruz. Herhangi bir sorunuz varsa lütfen iletişim desteği ile iletişime geçin.

2. 22 Temmuz 2026 09:52 UTCinvestigating

   takım sorunu ve bir sonraki adımları araştırmaya devam ediyor. Sabrınız için teşekkürler.

3. 22 Temmuz 2026 10:55 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

4. 22 Temmuz 2026 14:47 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 11 Temmuz 2026 07:53 UTCinvestigating

   Şu anda, ABD projelerinde kayıtlı olan projeler için gerçek zamanlı verileri etkileyen veri boru hattımızda gecikmeler yaşıyoruz, bu da bir alt proje için gecikmelere yol açıyor. Hiçbir veri kaybedilmediğinde, mühendislik ekibimiz aktif olarak gerçek zamanlı işlevselliği mümkün olduğunca çabuk geri yüklemek için çalışıyor. Bu süre boyunca sabrınızı takdir ediyoruz. Herhangi bir sorunuz varsa lütfen iletişim desteği ile iletişime geçin.

2. 11 Temmuz 2026 09:17 UTCinvestigating

   Bu konuyu araştırmaya devam ediyoruz.

3. 11 Temmuz 2026 10:15 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

4. 11 Temmuz 2026 12:54 UTCidentified

   Bu sorun için bir düzeltme üzerinde çalışmaya devam ediyoruz.

5. 11 Temmuz 2026 14:25 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

6. 11 Temmuz 2026 15:54 UTCresolved

   Bu olay çözüldü.

7. 16 Temmuz 2026 23:47 UTCpostmortem

   # Özet Yaklaşık **11:35 PM PT 10 Temmuz'da ve 7:19 AM PT 11 2026 - ABD bölgesinde Mix Panel projeleri için veri kesintisi iki saate kadar geride kaldı. Bu pencerede, raporlar ve panolar geçici olarak eksik veriler gösterdi - son zamanlarda aralıklar aktif kullanıcılar veya gelir gibi ölçümlerde keskin, yapay damlalar görünebilir. ** Hiçbir veri kaybedilmedi. ** Tüm olaylar sürekli olarak sıralandı ve gerilog temizlendikten sonra işlendi; metrikler kendi başlarına doğru değerlere geri döndüler, hiçbir müşteri eylemi gerekli değildi. Sebep, ingestion kontrollerimizde ortaya çıktı: Küçük bir çok yüksek hacimli proje için, izin verilen ingestion oranları, bu projeler için kapasiteye uygun olarak ayarlandı. Büyük tarihsel ithalat - platformun tamamen meşru kullanımı - bu nedenle altyapılarının absorbe edebileceğinden daha hızlı kabul edildi ve boru hattımızın iki özelliği yerelleştirilmiş aşırılıkların bir bölgeye kadar gecikmeye yol açtı. Gerçek o kontrollerin altındaki düzeltmeler, böylece herhangi bir ithalat, herhangi bir boyutta, otomatik olarak güvenli sınırlar içinde tutulur. # Ne oldu Mix Panel'in engestion boru hattı sharded ve multi-tenant: Her projenin verileri beklenen hacmi için bir dizi bölümle dağıtılır ve çoğu müşteriden gelen olaylar birlikte işlenir. Bu tasarım yüksek verimlilik sağlar, ancak bir değişkene bağlıdır: Bir projenin trafiğini kabul ettiğimiz oranı bunun için kapasiteye uygun olmalıdır. Bu değişmez tutarken, çok büyük ithalat bile sorunsuz bir şekilde absorbe edilir. İşte, tutmadı. Çok büyük bir tarihsel veri ithalatı, zaman içinde ingestion oranlarına izin verilen projeler üzerinde koştu, geçici bölme kapasitesinin ötesinde iyi büyüdü. Aşırı hacim, **hot spotlar** olarak belirli bölümlere yoğunlaştı, onlara hizmet eden akış filosunun kısmını atla. İki faktör sonra etkisini genişletti: * **Batched, multi-tenant işleme sıcak noktaları güçlendirdi.** Çünkü birçok müşteriden gelen olaylar, aşırı bölmelerdeki yavaşlık ve başarısızlıklar, bu topluları paylaşan ilişkili olmayan müşterilerin olayları geciktirdi. * **Otomatik ölçeklendirme etkisizdi.** Kapasite eklemek bu tür sıcak bir noktayı çözemez, çünkü aşırı bölmeler aynı altyapıya kilitlenir ve akış altyapımızın bir bileşeninde bir kapasite limiti, ek kapasitemizi etkileyerek engelledi. Birlikte, bunlar, manuel müdahale gerektiren çok saatlik bir gecikmeye kısa, kendini kınayan ne olmalıdır. # Timeline \(Pacific Time, 10-11\) * **11:35 PM** – İngestion backlog'u tespit eden otomatik uyarı; on-call mühendisi hemen meşgul. * **12:49 AM** - Durum sayfası olayı yayınlandı; ABD bölgesine sadece etkilendi. * **1:23 AM** – En büyük katkıda bulunan ithalat duraklandı. * **1:55-6:48 AM ** - İlerici mitigations: ek trafik kaynakları throttled, belirli geri kalan veriler kendi anlaşma ile ertelendi, arıza izolasyonu boru hattında etkinleştirdi ve etkilenen altyapı düğümleri değiştirildi. * **7:19 AM** – Backlog tamamen işlendi; mevcut tüm projeler. Durum sayfası izlemeye taşındı, sonra istikrarlı bir gözlem periyodundan sonra çözdü. # Kök neden 1. **Engestion oranı, geçici kapasiteyle yanlış sınırlar.** Sürücü projeleri için, kabul edilen platformlarımızın oranları, onlar için verilen altyapı ile adımdan büyüdü, bu nedenle meşru yüksek hacimli ithalat, bölümlerinden daha hızlı bir şekilde faydalanabiliyordu. Bu sistemsel kök nedenidir. ithalat kendileri platformun meşru bir kullanımıydı. 2. **Batched, multi-tenant işleme aşırı yüklemeyi güçlendirdi.** Aşırı bölmelerdeki başarısızlıklar, ilgili müşterilerin olayları ile aynı işleme toplularını paylaşıyor, platformda yerelleştirilmiş bir problem yayılıyor. 3. **Kayıtlı bölmelere yönelik araştırmalar yeniden dağıtılamaz.** Akış katmanında yer alma-server ataması yük-aware değildi, bu yüzden sıcak noktalar filo büyüklüğüne bakılmaksızın aynı sunuculara alındı - toplam kapasite yeterliydi, ancak ayıklanamadı. Akış altyapımızın bir bileşeninde ölçeklendirme limiti bunu, mühendislere manuel olarak müdahale edene kadar ölçeklendirmeyi engellemekle birleştirir. #Değiştiğimiz şey Binaya doğru inşa ettiğimiz son durum: ** Tüm proje yetersizlik limitleri otomatik olarak teslim edilmiş kapasiteyle eşleştirilir, böylece tam tarihsel geri dolumlar ve veri depo senkronizasyonları dahil olmak üzere herhangi bir boyut ithal edebilir ve bir projenin hacmi başka bir veri tazeliğini etkilemeye engellenir.**. Daha şimdiden konuşuluyor - ingestion işlemlerini geliştirmek: * ** Sıcak nokta işlemeyi geliştirdim.** Akış katmanındaki trafik dağılımı şimdi yük-aware, filosunda daha da yoğunlaştı ve bireysel sorun öğeleri şimdi geri kalanının tutulması yerine ayrı ayrı olarak yeniden beslenmektedir - ortadan kaldırmamasına rağmen, yerelleştirilmiş bir aşırı yüklemenin ilgili olmayan trafik üzerinde etkisi olabilir. * **En yüksek hacimli iş yüklerini tahmin edin; uygun büyüklükteki altyapıya, riskle öncelik verdi. Zaten dağıtılmıştı - üçüncü taraf akış hizmetini nasıl işlettiğimizi değiştirmek: * ** Filonun kapasite profilini tekrarladı ve geri çekildi ** böylece bireysel sunucular yoğun yük için çok daha fazla oda var ve olay sırasında karşılaşılan ölçeklendirme sınırlamasını çözmek için sağlayıcı ile çalıştı. İlerleme: * **Capacity-aware oranı sınırlaması - bireysel olarak verilen proje oranı limitleri ve her projenin gerçek teslim kapasitesi, daha önce eksik olan yollara sınırlamak ve herhangi bir gelecekteki limit artışını tekrarlamak için tasarlanmıştır. * **Finer-grained volume izleme ve uyarılama** bu kadar kapasite yanlışlığı tespit edilir ve herhangi bir müşteriyi etkilemeden önce düzeltilir. * Daha güçlü iş yük izolasyonu / gerilog kurtarma, toplu / geri yükleme trafiği yollarına öncelik verir, bu yüzden tarihsel ithalat canlı trafik üzerindeki etkisini azaltmıştır # Ortak sorular * ** Herhangi bir veri kayboldu mu?** No. Etkinlikler olay boyunca oldukça sıralandı ve gerilog temizlendikten sonra tamamen işlendi. Pencere sırasında görülen herhangi bir metrik damla, gecikme ve kendini kurtarılanın bir göstergesiydi. * ** Büyük ithalat veya Mix Panel ile geri yüklemeleri koordine etmem gerekiyor mu?** Hayır, Amacımız, güvenli oranlarda otomatik olarak herhangi bir ithalat tutmak için platform içindir, böylece depo ve depo senkronizasyonları zamanlama veya fark olmadan çalıştırılabilir. Biz hala bunu teslim eden kapasite farkında kontrolleri yapıyoruz. Bu arada, alışılmadık derecede büyük bir ithalat ya da geri yüklemeyi planlıyorsanız, hesap ekibinizle koordinasyonu tavsiye ederiz, böylece önceden kapasiteyi onaylayabiliriz. * **Bu nasıl ileriye gidiyor?** Sistemsel düzeltme, bireysel olarak verilen proje oranı limitleri ile her projenin gerçek teslim edilen kapasitesi arasında boşlukları sıkılaştırır ve daha önce eksik olan ingestion yollarına sınırlamak - bu tür aşırı yükleme kabul edilir. Buna ek olarak, olayı uzatan ölçeklendirme sınırlaması, boru hattı şimdi ayrı ayrı ayrı ayrı ayrı ayrı ayrı ayrı ayrı ayrı ayrı ayrı ayrı bir aşırı yükleme ile ilgili olmayan trafik üzerinde çok daha az etkiye sahiptir ve toplu trafik canlı trafikten daha izole edilmiştir. * ** Bireysel projeler kurtarma sırasında önceliklenebilir mi?** Bu yetenek olay sırasında yoktu - tüm projeler aynı oranda iyileşti. Takip çalışmamızın bir parçası olarak gerilog kurtarma için öncelik mekanizmaları değerlendiriyoruz. Bozukluk için özür dileriz ve geçici olarak depresif ölçümlerin neden olduğu endişe için. Lütfen hesabınız ekibinden veya herhangi bir soru ile destek alın.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 29 Haziran 2026 19:47 UTCinvestigating

   Mix Panel, Sorgu API ile bozulan performansı deneyimliyor, artan gecikme dahil. Yavaş yükleme raporları veya sorgu hataları görebilirsiniz. Mühendislerimiz normal işlevselliği geri yüklemek için çalışırken sabrınızı takdir ediyoruz. Durum sayfamızda ilerleme güncellemelerini yayınlayacağız. Herhangi bir sorunuz varsa lütfen iletişim desteği ile iletişime geçin.

2. 29 Haziran 2026 21:04 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

3. 29 Haziran 2026 22:42 UTCidentified

   Sorgu latency stabilize edilmiş olsa da, ekibimiz bozulan performansın temel nedenini incelemeye devam ediyor. Araştırma ilerlemelerimiz olarak güncellemeler yayınlamaya devam edeceğiz. Sabrınız için teşekkür ederiz.

4. 30 Haziran 2026 02:15 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

5. 30 Haziran 2026 03:30 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 3 Haziran 2026 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 Haziran 2026 20:17 UTCidentified

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

3. 3 Haziran 2026 21:27 UTCresolved

   This incident has been resolved.

1. 2 Haziran 2026 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 Haziran 2026 12:31 UTCidentified

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

3. 2 Haziran 2026 14:31 UTCmonitoring

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

4. 2 Haziran 2026 16:53 UTCresolved

   This incident has been resolved.

1. 1 Haziran 2026 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 Haziran 2026 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 Haziran 2026 15:29 UTCidentified

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

4. 1 Haziran 2026 16:38 UTCmonitoring

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

5. 1 Haziran 2026 19:42 UTCresolved

   This incident has been resolved.

1. 19 Mayıs 2026 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 Mayıs 2026 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 Mayıs 2026 20:23 UTCmonitoring

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

4. 19 Mayıs 2026 21:18 UTCresolved

   This incident has been resolved.

1. 14 Mayıs 2026 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 Mayıs 2026 23:48 UTCidentified

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

3. 15 Mayıs 2026 10:19 UTCidentified

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

4. 15 Mayıs 2026 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 Mayıs 2026 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 Mayıs 2026 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 Mayıs 2026 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 Mayıs 2026 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 Mayıs 2026 21:23 UTCidentified

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

10. 15 Mayıs 2026 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 Mayıs 2026 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 Mayıs 2026 01:52 UTCmonitoring

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

13. 16 Mayıs 2026 02:50 UTCresolved

    This incident has been resolved.

14. 21 Mayıs 2026 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 Mayıs 2026 16:34 UTCidentified

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

2. 13 Mayıs 2026 21:40 UTCidentified

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

3. 14 Mayıs 2026 13:35 UTCresolved

   This incident has been resolved.

1. 12 Mayıs 2026 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 Mayıs 2026 17:46 UTCidentified

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

3. 12 Mayıs 2026 20:24 UTCmonitoring

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

4. 12 Mayıs 2026 21:44 UTCresolved

   This incident has been resolved.

1. 6 Mayıs 2026 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 Mayıs 2026 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 Mayıs 2026 20:04 UTCresolved

   This incident has been resolved.

1. 9 Nisan 2026 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 Nisan 2026 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 Nisan 2026 21:44 UTCresolved

   This incident has been resolved.

1. 16 Mart 2026 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 Mart 2026 19:29 UTCmonitoring

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

3. 16 Mart 2026 21:47 UTCresolved

   This incident has been resolved.

1. 2 Mart 2026 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 Mart 2026 21:09 UTCidentified

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

3. 2 Mart 2026 21:09 UTCmonitoring

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

4. 2 Mart 2026 21:53 UTCresolved

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

1. 2 Mart 2026 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 Mart 2026 19:49 UTCidentified

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

3. 2 Mart 2026 19:50 UTCmonitoring

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

4. 2 Mart 2026 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 Mart 2026 01:43 UTCresolved

   This incident has been resolved.

1. 2 Mart 2026 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 Mart 2026 18:44 UTCidentified

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

3. 2 Mart 2026 18:45 UTCmonitoring

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

4. 2 Mart 2026 18:53 UTCresolved

   This incident is resolved.

1. 30 Ocak 2026 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 Ocak 2026 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 Ocak 2026 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 Ocak 2026 01:48 UTCmonitoring

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

5. 31 Ocak 2026 02:41 UTCresolved

   This incident has been resolved.