Mixpanel の障害履歴

1. 2026年10月21日 18:04 UTCmonitoring

   We’ve received reports that requests to decide.mixpanel.com are failing. Any traffic sent through decide.mixpanel.com may be affected, including feature flags and event tracking. To restore service now, point requests to api.mixpanel.com (US), api-eu.mixpanel.com (EU), or api-in.mixpanel.com (IN) depending on your project's Data Residency. We’re rolling out a mitigation and monitoring the results. We will post progress updates on our status page. If you have any questions, please contact support.

2. 2026年10月21日 20:15 UTCresolved

   This incident has been resolved.

1. 2026年10月21日 22:28 UTCmonitoring

   決定するリクエストのレポートを受け取りました。mixpanel.com が失敗しています。 決定.mixpanel.comを介して送信されたトラフィックは、機能フラグとイベントのトラッキングを含む影響を受ける可能性があります。 今すぐサービスを復元するには、api.mixpanel.com (米国)、api-eu.mixpanel.com (EU)、またはapi-in.mixpanel.com (IN) へのリクエストを、プロジェクトのデータレジデンシーに応じて処理します。 緩和をロールアウトし、結果を監視しています。 交通の回復が見られます。 ステータスページで進捗更新を投稿します。 ご不明な点がございましたら、お気軽にお問い合わせ下さい.

2. 2026年10月22日 1:34 UTCresolved

   この事件は解決しました.

3. 2026年10月24日 1:58 UTCpostmortem

   #**Mixpanel RCA: リクエスト** [**decide.mixpanel.com**](http://decide.mixpanel.com)**失敗、10月15日〜21日、2026** ##**概要** 2026年10月15日から10月21日にかけて、`decide.mixpanel.com` と `api-decide.mixpanel.com` に送信されたリクエストは失敗しました。 この影響を受けたお客様は、イベントの追跡、プロフィールの更新、または機能フラグのリクエストをこのホスト名に送った場合、通常はプロキシを通して送信されます。 このウィンドウに送信されたイベントは、Mixpanelによって受信されず、このデータはMixpanelによって復元できませんでした。 **"api.mixpanel.com`**,** `api-js.mixpanel.com,`api-eu.mixpanel.com`**,**`api-in.mixpanel.com`**,**`api-in.mixpanel.com`**,```````} に送信されました。** `/decide` エンドポイントのインフラを外していたときに、このホスト名に対するサービスが意図的に影響されなかった。 ホスト名は、システム依存性の誤った理解のためにエンドポイントの一部として扱われました。 この問題のクラスを防ぐため、 `decide.mixpanel.com` と `api-decide.mixpanel.com` のホスト名に対するトラフィック監視を追加します。 ホスト名が削除される前に、ホスト名レベルで確認されたゼロトラフィックも必要です。 **弊社は、** `decide.mixpanel.com` 上でサービスを復元するので、. ##**何が起こったのか 古いMixpanel SDKは、[**Legacy自動追跡モバイルイベント**](https://docs.mixpanel.com/docs/tracking-methods/sdks/ios#legacy-automatically-tracked-events)の構成をフェッチする`/decide`エンドポイントと呼ばれる。 [エンドポイントの退職金をお知らせ](https://docs.mixpanel.com/changelogs#2026-01-26)、しばらくの間 `/decide` は `410` 応答を返しました。 別々に、`decide.mixpanel.com` と `api-decide.mixpanel.com` は標準 API ホスト名に対するエイリアスとして機能しました。 たとえば、`decide.mixpanel.com/track` は、`api-js.mixpanel.com/track` と同じ方法でイベントを摂取しました。 一部の顧客は、プロキシやSDKの設定を設定して、これらのホスト名にトラフィックを送信しました。 10月15日(水)午後7時40分に「/decide」エンドポイントの最終クリーンアップ時に「decide.mixpanel.com」と「api-decide.mixpanel.com」のDNSレコードを削除し、ロードバランサから両方のホスト名を削除しました。 変更をする前に、 `/decide` エンドポイントへのトラフィックがゼロに低下したことを確認しました。 ただし、ホスト名ではなくエンドポイントで計測したトラフィックを監視します。 したがって、`/track` や `/flags` などの他のリクエストは、これらのホスト名を介した Mixpanel にまだ到達していたことが示されていない。 それから、`/track`、`/engage`、`/groups`、および`/flags`などのエンドポイントを含む、このホスト名に対するすべてのリクエストは失敗しました。 ***イベントとプロフィール:**イベント、プロフィール、および[Ingestion API endpoints](https://docs.mixpanel.com/reference/ingestion-api)を対象とするデータが、このウィンドウにMixpanelに達していないため、復元するコピーはありません。 プロキシログやデータウェアハウスなど、このデータを他の場所で保持している場合は、Ingestion API の [/import](https://docs.mixpanel.com/reference/import-events)、 [/engage](https://docs.mixpanel.com/reference/profile-set)、 [/groups](https://docs.mixpanel.com/reference/profile-set)、 [/groups](https://docs.mixpanel.com/reference/groups)、および [/groups](https://docs.mixpanel.com/reference/group-proper.com/config-proper.com/ ***特徴の旗:** これらのホスト名に送信された機能フラグリクエストは失敗しました。 SDK は、存在していた場合、またはコードで設定されたフォールバック値が最後に保存された variant を扱いました。 ## タイムライン \(中央時間、10月2026\) ※10月15日(日)19:00まで ホスト名除去が適用されます。 `decide.mixpanel.com` と `api-decide.mixpanel.com` へのリクエストは失敗します。 ※10月16日(日)5:22 受付:** 初めてのお客様レポートをお送りします。 当初は計画された `/decide` 退職に関連することが理解されます。 * 10月21日(月)11:42 AM CDT:** プロキシの失敗を追跡することについての顧客のレポートの増加に続いて、我々は原因としてホスト名除去を識別します。 * 10月 21, 12:26 PM CDT:** ホスト名を復元する `/decide` は退任したままです。 ※10月21日(月)1:51 PM CDT:** 復元されたホスト名へのトラフィックが回復していることを確認します。 * 10月21日(日)8:34 PM CDT:** 事件は解決されます。 ##**ルート原因** 1. `/decide` 退職中に `decide.mixpanel.com` と `api-decide.mixpanel.com` は意図せずに削除されました。 2。 これらのホスト名は、 `/decide` リクエストだけでなく、すべての API トラフィックを受け入れるように構成され、この動作はドキュメント化されていない。 3. 当社の監視は、`/decide` エンドポイントへのトラフィックを追跡しましたが、これらのホスト名には表示されませんので、事前変更チェックは、他のトラフィックがまだアクティブであることを示しませんでした。 4。 ホスト名と退職エンドポイントの名前を共有するため、早期の顧客レポートは、発表された`/decide`退職の期待された効果として最初に解釈されました。 この遅延エスカレーション。 ##**変更する理由** ***監視と警告:** `decide.mixpanel.com` と `api-decide.mixpanel.com` のトラフィックとエラーレートの監視とアラートを追加しましたので、顧客レポートではなく自動的に失敗が検出されます。 ***ホスト名監査:** 一般的な API ホスト名とルーティングのエイリアスを、同様のドキュメントされていないエントリ ポイントを監査し、新しいホスト名とエイリアスをライブ前に見直します。 また、予期しないホスト名に到着するトラフィックを追跡しています。 * **より安全な取り外し:** パブリックホスト名への将来の変更前に、ホスト名レベルでのゼロトラフィックが確認され、使用中のプロジェクトを識別し、連絡します。 ***お客様の通信:** 変更ログにタイムライン上に公開するなど、公共のホスト名に影響を及ぼす材料インフラの変更をお客様に事前に通知します。 **既に導入:** ※「decide.mixpanel.com」と「api-decide.mixpanel.com」を復元 * `/decide` は退任したまま ###**Common 質問** *ただし、データが影響を受けた場合 SDK やプロキシが 10 月 15 日から 10 月 21 日までに `decide.mixpanel.com` または `api-decide.mixpanel.com` にリクエストを送信した場合のみ。 そのウィンドウの間に送信されたデータは受信されず、Mixpanelによって復元できませんでした。 そのデータのコピーを保持している場合は、イベントの `/import` などの Ingestion API エンドポイントを使用して、Mixpanel に再送信できます。 ※ 変更は必要ですか?** いいえ、ドメインは再び機能します。 API ドメインとして `api.mixpanel.com`\(または `api-eu.mixpanel.com`/`api-in.mixpanel.com` を EU および India のデータレジデンシー\ に使用することをお勧めします。 *** `/decide` が返ってくる? いいえ。 退会したままで、 `decide.mixpanel.com` ホスト名とは別です。 申し訳ございません。 プロジェクトに関する質問がある場合は、アカウントチームまたはMixpanelサポートにお問い合わせください.

公式のインシデント更新を自動翻訳しています。

1. 2026年10月8日 16:32 UTCinvestigating

   現在、米国プロジェクトに登録されたプロジェクトにリアルタイムデータに影響を及ぼし、プロジェクトのサブセットの遅延が発生しています。 データが失われることはありませんが、エンジニアリングチームは、問題を積極的に調査し、リアルタイムの機能を迅速に復元します。 誠に有難うございます。 ご不明な点がございましたら、お気軽にお問い合わせ下さい.

2. 2026年10月8日 17:32 UTCidentified

   問題が特定され、修正が実装されています.

3. 2026年10月8日 18:31 UTCidentified

   クラウドストレージプロバイダー、Google Cloud による上流の問題として、インジェクション遅延の原因を特定しました。 Googleは、最終的には高い優先性の問題として確認しましたが、まだETAを提供していません。 クリアするとスムーズなリカバリを確保するために、緩和を導入しました。 イベントを失わない これは、問題が解決されると、影響を受けたデータはすべて再処理されます.

4. 2026年10月8日 19:30 UTCmonitoring

   弊社のメトリクスショーのインジェクションが巻き込まれ、遅延が発生しません。 Googleは、まだ自分の端に上流の問題の解決を確認していないので、再発の場合、密接に監視しています.

5. 2026年10月8日 21:30 UTCmonitoring

   最終更新以降は変更せず、最後までは積極的な摂取遅延を観察し続け、全てのシステムが健全です。 今後も監視を続けてまいります.

6. 2026年10月8日 22:30 UTCmonitoring

   今後の問題がないか引き続き監視しています。

7. 2026年10月8日 23:30 UTCmonitoring

   システムは、摂取遅延の再発なしで安定しています。 上流プロバイダから最終確認をお待ちしています.

8. 2026年10月9日 0:22 UTCresolved

   この事件は解決しました。 クラウドストレージプロバイダによる上流の問題は修正され、私たちのインジェクションパイプラインは、アクティブな遅延なしで正常に動作しています。 この事件でイベントが失われたことはなく、影響を受けたデータはすべて完全に再処理された。 この事件を通しまして誠に有難うございます.

公式のインシデント更新を自動翻訳しています。

1. 2026年8月26日 21:39 UTCinvestigating

   Mixpanel は、クエリ API のパフォーマンスを劣化させ、米国のデータレジデンシーとのプロジェクトに関するレポートをクエリする際に HTTP 500 レスポンスを生成します。 EUとイン・データ・レジデンシーのプロジェクトは影響を受けません。 エンジニアが正常な機能性を回復させるために働く間、あなたの忍耐を感謝します。 ステータスページで進捗更新を投稿します。 ご不明な点がございましたら、お気軽にお問い合わせ下さい.

2. 2026年8月26日 22:11 UTCidentified

   問題が特定され、修正が実装されています.

3. 2026年8月26日 22:28 UTCmonitoring

   修正が実装され、クエリ API の成功率が向上しました。 今後もモニタリングを続けてまいります.

4. 2026年8月26日 22:45 UTCresolved

   この事件は解決しました.

5. 2026年9月8日 18:25 UTCpostmortem

   #Mixpanel RCA:米国プロジェクトのための一時的な問い合わせサービス中断 8月 26, 2026 # まとめ 2026年8月26日の午後2時02分と午後3時19分の間、アメリカ地域のプロジェクトは、Mixpanel UIとクエリAPIを通じてレポートをロードし、クエリを実行した経験しました。 このウィンドウでは、領域のクエリが失敗したり、エラーが返されたりします。 **顧客データが失われず、データ摂取は影響を受けません。** すべてのイベントは、インシデント全体で通常収集および保存され続ける; クエリサービスが復元されたら、すべてのレポートは、顧客行動を必要としない完全で正確なデータを反映した。 原因は、診断クエリの再生のための最近展開された内部ツールとして識別されました, 私たちのエンジニアは、過去のクエリのコピーを再実行するために使用能力は、パフォーマンスをデバッグします, 予期せず、私たちのクエリサーバのディスクに大量のデータを書いた, ストレージ容量を消費して、サーバは動作する必要があります. これらのディスクが満たされたとき、影響を受けたサーバーはサービスから取り出しました。 本サービスは復元され、影響を受けたサーバーがオンラインに戻り、内部ツーリングが無効になりました。 下の修正は、クエリサーバーにリソースを消費する内部ツーリングの能力を削除するためのストレージ保護策を追加し、将来的に起きている問題のこのクラスを防ぐように設計されています。 # 何が起こったのか Mixpanelのクエリエンジンは、各サーバーの一連のローカルストレージボリュームを使用して、クエリを迅速に解決するために必要なデータをキャッシュします。 別々に、当社のエンジニアは、診断クエリの再生ツールを使用して、当社のエンジニアがクエリのパフォーマンスを再現し、デバッグするために使用する機能を使用します。 大規模な複雑なクエリに診断クエリの再生ツールを適用している間、クエリの再生キャプチャは、単一のサーバーに閉じ込められた代わりに、艦隊全体でファンアウトする。 また、1つのサーバーでタイムリーな操作をせずに保存する予定よりもはるかに多くのデータを引き起こしました。 2つの要因は、問題の影響を広げました。 * 1つのフルストレージのボリュームは、サーバーを完全にサービスから取り出しました。 各サーバーは、すべての他のボリュームが健康である場合でも、そのストレージボリュームのいずれかが使用しきい値を渡るならば、不健康なようにキャッシュを扱います。 再生データは、サーバー毎の特定のボリュームに書かれていたため、地域全体のサーバーは、ほぼ同時に健康チェックを失敗しました。 ※ クリーンアップの制限はデータサイズを考慮していません。 ファイルシステムレベルでバイトではなく、アプリケーションレベルでディスクのカウントされた項目にリプレイデータを制限する保護策なので、大量の容量のほとんどを消費しながら、予期しない大量のキャプチャがチェックを通過しました。 これらは、通常、米国地域を横断する生産クエリを中断するために、必須のフットプリントを持っている単一のデバッグワークフローを許可しました。 # タイムライン \(太平洋時間、8月26日、2026\) ***2:00 PM** — 第一サイズ診断再生キャプチャが書かれていました。 ストレージのボリュームは、容量とクエリの成功率に達するようになりました。 ※2:17 PM** — オンコールエンジニアを自動警戒し、調査が始まり、追加のエンジニアが従事しました。 ※2:39 PM** — ステータスページインシデント投稿、アプリ内バナーは2:40 PMに表示。 ※2:53 PM** — ルートが特定された原因; 回復努力は最初の影響を受けたサーバーグループで始まりました。 ***3:19 PM** — トラフィックの大半のために復元されたクエリサービス。最終サーバーグループは3:27 PMで完全に回復しました。 ※3:45PM — 安定した観測期間を過ぎて解決した場合 問題を引き起こした診断再生ツールは、同じ夕方を完全に無効化しました。 # 根本原因 1。 **当社のクエリ再生ツールのソフトウェアのバグは、生産ストレージへの未踏の書き込みを引き起こしました。** 複雑なクエリの特定のクラスを誤ったクエリを生成するための最近展開された機能により、キャプチャは地域内のすべてのクエリサーバーにスプレッドし、想定される設計よりも影響を受けるボリュームに遠くのデータを書き込むことができます。 2。 **再生ファイルは、クエリサービングが依存するディスク容量を消費しました。** 再生ツールは、クエリサーバーのローカルディスクにファイルを書きました。そのため、実行中の再生データが、サーバーはクエリに応答する必要があります。 3。 **行動のために部分的に考慮されるだけを保護して下さい。** 診断再生データのためのクリーンアップポリシーは、ディスク上のアイテムの数が限られているが、その合計サイズではなく、それに従事しなかった。 ストレージボリュームのアラートは、成長を強調したが、サーバー単位で重要なものとしてエスカレーションされていないため、クエリの失敗が始まったまで検出を遅延させました。 # 変化する 私たちが構築しているのは、専用のオブジェクトストレージに保存された内部診断クエリ再生データです。プロダクションクエリサーバーに負荷をかけません。 既にデプロイされる: ***インシデントを引き起こした内部ツーリング**を無効化し、根本的な問題を修正し、診断キャプチャは単一のサーバーに限定され、特定のクエリクラスが正しく処理されます。 *** 対象となる回復手順** をインシデント中に使用し、すなわち、フルサーバーグループを再起動するのではなく、影響を受けるストレージ容量だけをクリアし、運用中のランブックで、将来のボリュームの容量がなくなると回復時間を短縮しました。 進行中: ***ファイルシステムレベル、診断再生データのサイズベースの制限**、アイテム数ではなく、ディスク上の合計バイトをキャッピングするので、大きすぎるキャプチャは、ボリュームの容量に影響を与えることができる前に拒否またはevictedされます。 ***Stricterストレージアラート**、クエリ健康チェックに影響を与えることができる前に、サーバーのボリューム飽和をクリティカルにエスカレートします。 ***クエリーのリプレイデータを専用のオブジェクトストレージに削除するので、プロダクションクエリサーバにリソースを消費しません。 # 一般的な質問 ***データが失われた場合 いいえ。 事件全体にデータ摂取が不満でした。イベントは収集、キューに入れ、正常に保存されます。 クエリが中断されただけ。 サービスが復元されたら、すべてのレポートは完全なデータを反映しています。 * 保存されたレポート、ダッシュボード、またはプロジェクト設定の影響を受けますか?** いいえ。 インシデントはクエリ実行のみに影響しました。 プロジェクトに格納されていないものは変更されません。 ***複数の米国のプロジェクトに一度に影響したのはなぜですか?** ほぼ同時に、すべてのクエリサーバのディスクに書かれている特大の診断再生データであり、各サーバーは1つのボリュームが満たしたときにサービスから削除されます。 クエリサーバのストレージを消費する内部ツーリングを防止することは、当社の是正作業のコア部分です。 ※この予防措置は?** 工具細工の問題は解決され、工具細工はサイズベースの限界が置かれるまで無効に残ります。 ストレージのアラートは締められており、クエリのサービングに影響を与える前に飽和がキャッチされます。 構造的に、私達は生産の照会サーバーを完全に動かします、従って内部のダバッギングデータは照会の処理を担当するサーバーの貯蔵を消費しません。 ご迷惑をおかけしますが、ご迷惑をおかけいたしますが、何卒ご了承くださいますようお願い申し上げます。 ご質問やご質問など、お気軽にお問い合わせ下さい.

公式のインシデント更新を自動翻訳しています。

1. 2026年8月19日 23:20 UTCidentified

   現在、ドロップダウンメニューのポップアップイベントのプロパティーの問題が発生しています。 エンジニアが機能性を回復するために働いている間、あなたの忍耐を感謝します。 ご不明な点がございましたら、[email protected]までご連絡ください

2. 2026年8月20日 1:04 UTCidentified

   この問題の修正には引き続き取り組んでいます。

3. 2026年8月20日 2:52 UTCmonitoring

   修正を実装し、結果を監視しています.

4. 2026年8月20日 3:05 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年8月6日 7: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. 2026年8月6日 8:39 UTCidentified

   The issue has been identified and fix is being implemented.

3. 2026年8月6日 9: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. 2026年8月6日 13:32 UTCresolved

   This incident has been resolved.

1. 2026年7月22日 8:03 UTCinvestigating

   現在、ウェブアプリ内でのMixpanelエージェントの問題が発生しています。 当社のエンジニアリングチームは、問題を調査し、その機能を回復するために働いています。 私たちはこの問題を解決するために働くので、あなたの忍耐を感謝します。 ご不明な点がございましたら、お気軽にお問い合わせ下さい.

2. 2026年7月22日 9:52 UTCinvestigating

   チームは、問題と次の手順を調査し続けています。 ありがとうございます.

3. 2026年7月22日 10:55 UTCmonitoring

   修正を実装し、結果を監視しています.

4. 2026年7月22日 14:47 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月11日 7:53 UTCinvestigating

   現在、米国プロジェクトに登録されたプロジェクトにリアルタイムデータに影響を及ぼし、プロジェクトのサブセットの遅延が発生しています。 データが失われることはありませんが、エンジニアリングチームは、問題を積極的に調査し、リアルタイムの機能を迅速に復元します。 誠に有難うございます。 ご不明な点がございましたら、お気軽にお問い合わせ下さい.

2. 2026年7月11日 9:17 UTCinvestigating

   今後もこの問題について調査を続けてまいります.

3. 2026年7月11日 10:15 UTCidentified

   問題が特定され、修正が実装されています.

4. 2026年7月11日 12:54 UTCidentified

   この問題の修正には引き続き取り組んでいます。

5. 2026年7月11日 14:25 UTCmonitoring

   修正を実装し、結果を監視しています.

6. 2026年7月11日 15:54 UTCresolved

   この事件は解決しました.

7. 2026年7月16日 23:47 UTCpostmortem

   # まとめ 2026年7月10日(水)、7月19日(水)午前7時19分に約11時35分に及ぶMixpanelプロジェクトへのデータ摂取量は最大2時間です。 このウィンドウでは、レポートとダッシュボードは一時不完全なデータを示しました。最近の時間範囲は、アクティブなユーザーや収益などのメトリックのシャープで人工的なドロップとして表示できます。 **データが失われない。** すべてのイベントは、バックログがクリアされたら、確実にキューに入れられ、完全に処理されました。 メトリックは、顧客行動は必要ありません。 私たちの摂取制御に由来する原因:非常に大量のプロジェクトのために、私たちが許可した摂取率は、これらのプロジェクトのために規定された容量とアライメントを解除しました。 大規模な歴史的インポート — プラットフォームの完全正当な使用 — したがって、インフラストラクチャが吸収できるよりも速く割り当てられ、パイプラインの2つのプロパティは、ローカライズされた過負荷を地域全体の遅延に変えました。 下の修正は、任意のサイズのインポートが安全な境界内で自動的に保持されるように、それらの制御を再調整します。 # 何が起こったのか Mixpanelの摂取パイプラインは、シャードとマルチテナントです。各プロジェクトのデータは、予想されるボリュームのサイズのパーティションのセットを渡って配布され、スループットのために、多くの顧客からのイベントはバッチで一緒に処理されます。 この設計は、高い効率性を提供しますが、それは1つの不変に依存します:プロジェクトのトラフィックを認める割合は、そのために規定する能力に一致しなければなりません。 その不変が保たれたとき、非常に大きい輸入は滑らかに吸収されます。 ここには、保持しませんでした。 混雑率が許されたプロジェクトに非常に大きな歴史的データインポートが実行され、時間をかけて、暫定的なパーティション容量を超えてよく成長しました。 過剰なボリュームは、**ホットスポット**として特定のパーティションに集中し、ストリーミング艦隊の部分を飽和させます。 2つの要因は影響を広げました: ***ホットスポットを増幅したマルチテナント処理。** 多くのお客様からのイベントは、積み過ぎた仕切りのバッチ、低さ、故障で一緒に旅行しているため、それらのバッチを共有している関係のない顧客のイベントを遅延させました。 ***自動スケールアップが無効になりました。** 積み過ぎた仕切りが同じインフラに固定され、当社のストリーミングインフラのコンポーネントの容量制限により、この種のホットスポットを溶解することはできません。 一緒に、これらは、マニュアルの介入を必要とする複数の時間の遅延に簡潔で自己治癒の減速だったものでした。 # タイムライン \(太平洋時間、7月10–11\) * **11:35 PM** — 自動化された警戒は、混雑バックログを検出しました。 オンコールエンジニアはすぐに従事しました。 ***12:49 AM** — ステータスページインシデントが投稿されました。米国地域のみの影響を受けます。 *1:23 AM ** — 最大のコントリビュートインポートがパユースされました。 ***1:55–6:48 AM** - 進行方向の緩和:追加のトラフィックソーススロットルド、特定のバックロックされたデータは、独自の顧客の合意、パイプラインで無効化された障害の分離、および影響を受けたインフラストラクチャノードが変更しました。 ***7:19 AM** — Backlog は完全に処理されます。全てのプロジェクトは現在のものです。 ステータスページを監視し、安定した観察期間後に解決しました。 # 根本原因 1。 **摂取率は、規定された容量と誤って制限します。** 運転プロジェクトの場合、プラットフォームが認めたレートは、それらのために規定されたインフラで段階的に成長していたため、正当な大量のインポートは、パーティションが吸収できるよりも速く許可されていました。 これは全身の根本原因です。 インポート自体はプラットフォームの正当な使用でした。 2. **掛けられた、多テナント処理は積み過ぎを増幅しました。** 積み過ぎた仕切りの失敗はプラットホームを渡るローカライズされた問題を広げる同じ処理のバッチを共有する無関係の顧客のでき事を遅らせました。 3. 積み過ぎた仕切りへのTrafficは再配分できませんでした。** ストリーミングレイヤーのサーバーへの割り当てはロードウェアではなく、フリートサイズに関係なく、ホットスポットは同じサーバーにとどまり、総容量が十分であったが、負担することができませんでした。 スケールアップを防止することにより、当社のストリーミングインフラのコンポーネントのスケール制限は、エンジニアが手動で介入するまでの診断を遅らせる。 # 変化する 私たちが構築する最後の状態:**everyプロジェクトでは、その約束された容量に自動的にマッチするインジェクション制限があり、完全な履歴書やデータ倉庫の同期を含むあらゆるサイズのインポートが、事前の調整なしで実行でき、1つのプロジェクトのボリュームは、別のデータの鮮度に影響を与えるのを防ぐことができます。**。 すでに導入済み — 摂取処理の改善: ***ホットスポットの取り扱いを改善しました。** ストリーミングレイヤーのトラフィック分布は、現在ロードアウェアであり、車両全体に集中した負荷を増加させ、個々の問題項目は、そのバッチの残りの部分を保持するのではなく、別々に取得されます。 排除しないと、ローカライズされた過負荷が関連しないトラフィックに及ぼす影響。 ※** リスクを優先する、適切な規模のインフラに、最高水準のワークロードを改定 すでに展開されている — サードパーティのストリーミングサービスをどのように動作するかを変更する: ※注記して、フリートの容量プロファイルを再度調整しました** そのため、個々のサーバーは、集中した負荷のためのほぼより多くのヘッドルームを持ち、プロバイダーと協力して、事件中に遭遇したスケーリング制限を解決しました。 進行中: ***Capacity-aware レートの制限** — 個別に付与されたプロジェクト率の制限と各プロジェクトの実際のプロビジョニング容量のギャップをクローズし、以前に欠けたインジェクションパスに制限するレートを拡張し、将来の制限が容量増加に増加し、このクラスが再発を防止するように設計されています。 ***Finer-grainedの容積の監視および警急**従って容量の不整列はあらゆる顧客に影響を与えることができる前に検出され、訂正されます。 * 大量の/バックフィルの交通経路のためのより強いワークロードの分離/バックログの回復優先順位の評価、従って歴史的輸入は生きている交通に影響を与えました # 一般的な質問 ***データが失われた場合 いいえ。イベントはインシデント全体で確実にキューに入れられ、バックログがクリアされたら完全に処理されていました。 ウィンドウの間に見られるメトリックのドロップは、遅延と自己補正のディスプレイアーティファクトでした。 ***Mixpanelで大きなインポートやバックフィルを調整する必要がありますか?** いいえ。 私たちの目標は、自動的に安全なレート内のインポートを維持するためのプラットフォームです, バックフィルと倉庫の同期は、スケジューリングや通知なしで実行することができますように. これを届けるキャパシティ・アウェア・コントロールを、まだまだロールアウトしています。 その間に、異常に大きなインポートやバックフィルを計画している場合は、アカウントチームと連携して、事前に能力を確認することができます。 ※この予防措置は?** 体系的な修正は、個別にプロジェクト率の制限と各プロジェクトの実際の暫定能力を付与し、以前に欠けている摂取経路に制限率を拡張するという点で、この種の過負荷は入学を中止します。 また、事件を延ばしたスケーリング制限は固定され、パイプラインは個別の問題項目を別々に取り除きますので、ローカライズされた過負荷は関連のないトラフィックにはるかに影響が少なく、バルクトラフィックはライブトラフィックからさらに分離されています。 ※※個人プロジェクトは回収時に優先できますか?** この機能は、インシデント中に存在しなかった - すべてのプロジェクトは同じレートで回復しました。 フォローアップ作業の一環として、バックログ回復の優先化メカニズムを評価しています。 万が一、原因となった一時停止したメトリックに、その混乱と懸念を心からお詫び申し上げます。 ご質問やご質問など、お気軽にお問い合わせ下さい.

公式のインシデント更新を自動翻訳しています。

1. 2026年6月29日 19:47 UTCinvestigating

   Mixpanel は、クエリ API を使用して、レイテンシの増加を含むパフォーマンスを劣化させています。 レポートやクエリエラーの読み込みが遅くなる可能性があります。 エンジニアが正常な機能性を回復させるために働く間、あなたの忍耐を感謝します。 ステータスページで進捗更新を投稿します。 ご不明な点がございましたら、お気軽にお問い合わせ下さい.

2. 2026年6月29日 21:04 UTCidentified

   問題が特定され、修正が実装されています.

3. 2026年6月29日 22:42 UTCidentified

   クエリレイテンシは安定していますが、当社のチームは劣化した性能の根本的な原因を調査し続けています。 今後も、調査の進捗を追って更新をしていきます。 ありがとうございます.

4. 2026年6月30日 2:15 UTCmonitoring

   修正を実装し、結果を監視しています.

5. 2026年6月30日 3:30 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年6月3日 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. 2026年6月3日 20:17 UTCidentified

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

3. 2026年6月3日 21:27 UTCresolved

   This incident has been resolved.

1. 2026年6月2日 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. 2026年6月2日 12:31 UTCidentified

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

3. 2026年6月2日 14:31 UTCmonitoring

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

4. 2026年6月2日 16:53 UTCresolved

   This incident has been resolved.

1. 2026年6月1日 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. 2026年6月1日 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. 2026年6月1日 15:29 UTCidentified

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

4. 2026年6月1日 16:38 UTCmonitoring

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

5. 2026年6月1日 19:42 UTCresolved

   This incident has been resolved.

1. 2026年5月19日 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. 2026年5月19日 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. 2026年5月19日 20:23 UTCmonitoring

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

4. 2026年5月19日 21:18 UTCresolved

   This incident has been resolved.

1. 2026年5月14日 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. 2026年5月14日 23:48 UTCidentified

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

3. 2026年5月15日 10:19 UTCidentified

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

4. 2026年5月15日 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. 2026年5月15日 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. 2026年5月15日 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. 2026年5月15日 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. 2026年5月15日 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. 2026年5月15日 21:23 UTCidentified

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

10. 2026年5月15日 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. 2026年5月16日 0: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. 2026年5月16日 1:52 UTCmonitoring

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

13. 2026年5月16日 2:50 UTCresolved

    This incident has been resolved.

14. 2026年5月21日 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. 2026年5月13日 16:34 UTCidentified

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

2. 2026年5月13日 21:40 UTCidentified

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

3. 2026年5月14日 13:35 UTCresolved

   This incident has been resolved.

1. 2026年5月12日 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. 2026年5月12日 17:46 UTCidentified

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

3. 2026年5月12日 20:24 UTCmonitoring

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

4. 2026年5月12日 21:44 UTCresolved

   This incident has been resolved.

1. 2026年5月6日 0: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. 2026年5月6日 9: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. 2026年5月6日 20:04 UTCresolved

   This incident has been resolved.

1. 2026年4月9日 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. 2026年4月9日 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. 2026年4月9日 21:44 UTCresolved

   This incident has been resolved.

1. 2026年3月16日 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. 2026年3月16日 19:29 UTCmonitoring

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

3. 2026年3月16日 21:47 UTCresolved

   This incident has been resolved.

1. 2026年3月2日 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. 2026年3月2日 21:09 UTCidentified

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

3. 2026年3月2日 21:09 UTCmonitoring

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

4. 2026年3月2日 21:53 UTCresolved

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