Honeybadger の障害履歴

1. 2026年8月15日 20:48 UTCresolved

   19:54 と 20:07 UTC の 8 月 15 日、US のエラー報告 API へのリクエスト (api.honeybadger.io) は、高い故障率を経験しました。 このウィンドウでは、エラーやイベントをタイムアウトまたは受信するリクエストの大部分が5xx応答を送信します。 ブラウザ(JavaScript)エラーレポート、ソースマップのアップロード、ハネバッガーウェブアプリケーション、ダッシュボード、稼働時間監視、およびEU地域は影響を受けていません。 何が起こったのか: 19:54 UTCで始まり、単一のソースは、約150倍の正常な速度でエラーレポートを提出し始め、ペイロードは平均よりも数倍大きい。 これは、私たちの摂取層に到着したデータの総量を1分以内に飽和させる倍以上のものです。 飽和サービスは、エラーアウトライトではなく、接続を受け付け続けたため、エラー応答を監視する自動スケーリングと警告 — 問題を迅速に登録しませんでした。また、問題が発生したよりも、容量が後で追加されました。 追加容量がオンラインで来れば20:07 UTCで回復サービス。 ほとんどの影響を受けたレポートは、APIが回復した後、クライアントライブラリによって正常に取得されたため、ウィンドウ中に送信された大量のデータが最終的に受信されました。 再試行ロジックなしでライブラリによって送信されたレポートは受信されず、復元できません。 私たちがやったこと:私たちのインジェクション層は、エラーレートに加えて、応答レイテンシをスケールアップしました。そのため、この種の飽和は、一度だけエラーが表示されるのではなく、分または2分以内に検出されます。 また、tierのベースライン容量を上げ、サーバーのエラーとして表面しない故障をカバーするために、当社のメッセージングアラートを広めました。 単一のソースが送信できるデータ量に制限を追加しています。 中断を申し立ててお詫び申し上げます。また、ウィンドウ中のエラーデータに生じたいかなるギャップについてもお詫び申し上げます.

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

1. 2026年7月8日 11:48 UTCresolved

   7 月 8 日、0622 日と 08:23 UTC の間、米国のエラー報告 API (api.honeybadger.io) へのリクエストは、非常に高い故障率を経験しました。 このウィンドウでは、エラー、イベント、およびチェックインが5xx応答を受け取った、またはタイムアウトされたリクエストのほとんど。 この期間中にリトライロジックなしでクライアントライブラリによって送信されたエラーレポートが受信されず、復元できませんでした。 Honeybadger Webアプリケーション、ダッシュボード、稼働時間監視、およびEU地域は影響を受けていません。 何が起こったのか: 06:18 UTC で始まり、通常の合計 API ボリュームを 3 回程度でエラーレポートを受信しました。 このトラフィックを摂取するサービスは一晩の能力レベルにあったし、飽和させた。 弊社の自動スケーリングは反応しましたが、故障したトラフィックを大幅に削減したメトリックは、その容量が遅くなるため、負荷をスケーリングし、吸収したときに全回復が0823 UTCに来ました。 問題のコンパウンド、PagerDuty のアラートは、ミスコンフィギュレーションのために人間を目覚めさせなかった。 私たちがやったこと: 基礎的なスケーリングの弱点を修正しました: API 容量は、ロードバランサーのエラーレートに直接スケールアウトします(特に、リクエスト率だけをスケールアウトし、そのスケーリングはすぐに応答しません)、そして、私たちは摂取層の最大容量を倍増しました。 これらの変更は、米国とEUの両方の地域に既に展開されています。 また、摂取サービスへの適応性パーキーレート制限を加える評価を行っています。 中断を申し立ててお詫び申し上げます。また、ウィンドウ中のエラーデータに生じたいかなるギャップについてもお詫び申し上げます.

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

1. 2026年3月12日 19:27 UTCresolved

   We had a backlog in our notifications queue that prevented timely delivery of alerts to channels such as Email, Slack, etc. The backlog has been processed as of 19:20 UTC. Our autoscaling rules for this service had a monitoring gap that prevented a scale-out to maintain a low latency on the queue. This monitoring gap has been resolved.

1. 2026年1月14日 20:40 UTCidentified

   A recent deploy has resulted in our rejecting some check-in API requests. We are in the process of deploying a fix.

2. 2026年1月14日 20:48 UTCresolved

   This incident has been resolved.

1. 2025年10月22日 19:46 UTCidentified

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

2. 2025年10月22日 20:15 UTCresolved

   This incident has been resolved.

1. 2025年10月22日 13:09 UTCidentified

   API ingestion of errors has been interrupted. We are deploying a fix.

2. 2025年10月22日 13:11 UTCmonitoring

   The US API has been restored, and the EU API restoration is in process.

3. 2025年10月22日 13:16 UTCresolved

   The EU API has been restored.

1. 2025年10月20日 13:44 UTCidentified

   Our error processing pipeline has been impacted by the AWS outage earlier this morning. Errors are being processed, but the end-to-end latency is much higher than normal. We are working to restore the processing to full capacity.

2. 2025年10月20日 17:55 UTCidentified

   We're continuing to monitor the AWS outage. Errors are being processed, but may be delayed. Uptime checks are also delayed, so you may notice lag with uptime notifications and status page updates.

3. 2025年10月20日 19:58 UTCmonitoring

   Processing has been restored and all systems are normal. We'll continue to monitor as AWS continues to restore service. Thanks!

4. 2025年10月20日 19:58 UTCresolved

   This incident has been resolved.

1. 2025年10月20日 13:36 UTCresolved

   Our systems were affected by the DynamoDB outage in AWS' us-east-1 region. Impacts included not being able to log use the web app, uptime checks not being executed on time, and check-ins being falsely reported as missing. We are evaluating what steps we can take to mitigate these kinds of impacts from this kind of outage in the future. Additionally, our status page was not updated in a timely manner due to our not having configured various AWS services as dependent components of our status page. We have fixed that issue, so future AWS outages will result in our status page automatically being updated.

1. 2025年2月12日 13:45 UTCresolved

   We had an interruption in processing of check-in alerts and in-app stats from about 12:30 to about 13:30 UTC. This may have resulted in a failure or a delay in reporting check-ins that went missing during that period.

1. 2024年10月22日 13:35 UTCmonitoring

   We have identified and corrected an issue in our data processing pipeline that may have caused delays for some customers. No data has been lost and the system should be caught up shortly.

2. 2024年10月22日 15:30 UTCresolved

   The backlog has been processed and all systems are running normally.

1. 2024年9月23日 10:37 UTCinvestigating

   We are looking into the cause of slowness and timeouts with the web app.

2. 2024年9月23日 11:48 UTCmonitoring

   We have identified the cause of the slowdown and performance is back to normal.

3. 2024年9月23日 11:57 UTCresolved

   This incident has been resolved.

1. 2024年7月24日 23:42 UTCidentified

   We have identified an issue with Insights event ingestion backlog. We are working on a fix.

2. 2024年7月25日 1:55 UTCmonitoring

   We have successfully pushed a fix and are waiting for the backlog to be processed. I also want to give a reminder that this only affects Insights events; error processing was unaffected.

3. 2024年7月25日 3:06 UTCresolved

   The backlog has been fully processed, so all Insights events should be ingested and available.

1. 2024年2月12日 20:22 UTCinvestigating

   We are seeing an increased backlog in our check-in processing, which is causing false alarms to be reported. We are investigating the cause of the backlog.

2. 2024年2月12日 20:39 UTCresolved

   We discovered and addressed a configuration issue that caused the delay in processing. Processing has returned to normal.

1. 2024年2月6日 20:59 UTCinvestigating

   We are currently experiencing elevated response times and timeouts from our web application.

2. 2024年2月6日 21:02 UTCinvestigating

   We are continuing to investigate this issue.

3. 2024年2月6日 21:42 UTCidentified

   We've identified an issue with aggregate database queries and are working on a fix.

4. 2024年2月6日 23:03 UTCmonitoring

   We've resolved an issue with query contention, and web application service has been restored. Our API pipeline was unaffected by this incident. Some charts on the reports tab may be outdated until we update project counts. We'll continue to monitor the situation. Sorry for the inconvenience!

5. 2024年2月6日 23:19 UTCresolved

   This incident has been resolved.

1. 2024年1月17日 19:19 UTCidentified

   We are working on restoring service

2. 2024年1月17日 19:21 UTCresolved

   This incident has been resolved.

1. 2023年11月10日 19:44 UTCresolved

   We discovered this morning that our Logplex pipeline, which handles Heroku platform errors, had an interruption in processing, which caused platform errors not to be recorded. This has been corrected, the backlog is being processed, and additional monitoring has been added to avoid this issue in the future.

1. 2023年6月13日 18:59 UTCidentified

   Issues with AWS Lambda are causing our uptime check reports to be delayed. Reports are queued up and will be delivered as AWS services recover.

2. 2023年6月13日 19:34 UTCidentified

   Search indexing and notice timeline charts are also impacted by the failures with Lamba. We're continuing to queue updates for processing once Lambda resumes normal operations.

3. 2023年6月13日 21:37 UTCresolved

   Lambda is back in business, and the backlog of events triggered during the outage is being processed.

1. 2023年3月25日 1:06 UTCresolved

   Starting around 3:30pm PST, we had an incident where an unhealthy API server was in rotation in our load balancer. During that time requests routed to that server responded with a 502 which could have resulted in the clients dropping notices. At around 5:30pm PST we removed the unhealthy server from rotation. 7:22pm PST edit: Reworded message to describe that notices are not queued on the client, but dropped when the server responds in an error state

1. 2023年3月24日 8:05 UTCinvestigating

   We currently are having issues processing our notice backlog. We are looking into the issue.

2. 2023年3月24日 8:40 UTCidentified

   We have identified the issue and are working towards clearing the backlog.

3. 2023年3月24日 9:01 UTCresolved

   We identified that our workers had an issue deploying. We deployed a fix and upped our capacity to deal with the current backlog. Everything is back to normal now. Turns out this issue was related GitHub rotating their public RSA key: https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/

1. 2023年3月9日 9:46 UTCresolved

   We had an incident (from 1:00 to 1:27 PST) where our apps were unresponsive. They have since recovered.