Störungsverlauf von Honeybadger

1. 15. August 2026 um 20:48 UTCresolved

   Zwischen 19:54 und 20:07 UTC am 15. August erlebten Anfragen an unsere US-Fehlermelde-API (api.honeybadger.io) eine erhöhte Fehlerrate. Während dieses Fensters hat eine Mehrheit der Anfragen zum Einreichen von Fehlern und Ereignissen 5xx Antworten erhalten. Browser (JavaScript) Fehlermeldungen, Quellkarten-Uploads, die Honeybadger-Webanwendung, Dashboards, Uptime-Überwachung und unsere EU-Region waren nicht betroffen. Was passierte: Ab 19:54 UTC begann eine einzelne Quelle, Fehlerberichte mit etwa dem 150-fachen ihrer normalen Rate einzureichen, wobei die Nutzlasten um ein Vielfaches größer waren als der Durchschnitt. Dies hat das Gesamtvolumen der Daten, die in unserer Einnahmeebene ankommen, mehr als verdoppelt, die innerhalb einer Minute gesättigt wurden. Da der gesättigte dienst weiterhin verbindungen akzeptierte, anstatt fehler direkt zurückzugeben, registrierte unser autoskalieren und alarmieren - die auf fehlerreaktionen achten - das problem nicht schnell, und die kapazität wurde später hinzugefügt, als es hätte sein sollen. Service erholte sich um 20:07 UTC, sobald zusätzliche Kapazität online ging. Die meisten betroffenen Berichte wurden von unseren Clientbibliotheken erfolgreich getestet, sobald die API wiederhergestellt war, so dass die große Mehrheit der während des Fensters übermittelten Daten letztendlich empfangen wurde. Berichte, die von Bibliotheken ohne Wiederholungslogik gesendet wurden, wurden nicht empfangen und können nicht wiederhergestellt werden. Was wir getan haben: Unsere Ingestion-Ebene skaliert jetzt zusätzlich zu den Fehlerraten die Antwortlatenz, so dass diese Art von Sättigung innerhalb von ein oder zwei Minuten erkannt wird und nicht erst, wenn Fehler auftreten. Wir haben auch die Basiskapazität der Stufe erhöht und unsere Paging-Benachrichtigungen erweitert, um Fehler abzudecken, die nicht als Serverfehler auftreten. Wir fügen zusätzlich Grenzen hinzu, wie viele Daten eine einzelne Quelle übermitteln kann. Es tut uns leid für die Störung und für Lücken, die dies in Ihren Fehlerdaten während des Fensters verursacht hat.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. Juli 2026 um 11:48 UTCresolved

   Zwischen 06:22 und 08:23 UTC am 8. Juli wurde bei Anfragen an unsere US-Fehlermelde-API (api.honeybadger.io) eine stark erhöhte Fehlerrate festgestellt. Während dieses Fensters erhielt eine Mehrheit der Anfragen zum Einreichen von Fehlern, Ereignissen und Check-ins 5xx Antworten oder wurde zeitversetzt. Fehlerberichte, die von Clientbibliotheken in diesem Zeitraum ohne Wiederholungslogik gesendet wurden, wurden nicht empfangen und können nicht wiederhergestellt werden. Die Honeybadger-Webanwendung, Dashboards, Uptime-Monitoring und unsere EU-Region waren nicht betroffen. Was passierte: Ab 06:18 UTC erhielten wir Fehlerberichte mit etwa dem Dreifachen unseres normalen API-Gesamtvolumens. Die Service-Ebene, die diesen Datenverkehr aufnimmt, befand sich auf ihrem Übernachtkapazitätsniveau und wurde gesättigt. Unsere Autoskalierung reagierte, aber die Metriken, auf die sie sich stützte, missten den ausgefallenen Verkehr erheblich, so dass die Kapazität viel zu langsam hinzugefügt wurde - die vollständige Erholung kam um 08: 23 UTC, als die Skalierung die Last aufholte und absorbierte. Um das Problem zu verschärfen, wurden PagerDuty-Warnungen nicht gefeuert, um einen Menschen aufgrund einer Fehlkonfiguration aufzuwecken. Was wir getan haben: Wir haben die zugrunde liegende Skalierungsschwäche behoben: Die API-Kapazität skaliert jetzt auch direkt auf Load-Balancer-Fehlerraten (zuvor haben wir nur auf Anfrageraten skaliert, und diese Skalierung reagiert nicht schnell genug), und wir haben die maximale Kapazität der Einnahmeebene verdoppelt. Diese Änderungen werden bereits sowohl in den USA als auch in der EU umgesetzt. Wir evaluieren auch das Hinzufügen von adaptiven pro-Key-Rate-Limiting zum Ingestion-Service. Es tut uns leid für die Störung und für Lücken, die dies in Ihren Fehlerdaten während des Fensters verursacht hat.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 12. März 2026 um 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. 14. Januar 2026 um 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. 14. Januar 2026 um 20:48 UTCresolved

   This incident has been resolved.

1. 22. Oktober 2025 um 19:46 UTCidentified

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

2. 22. Oktober 2025 um 20:15 UTCresolved

   This incident has been resolved.

1. 22. Oktober 2025 um 13:09 UTCidentified

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

2. 22. Oktober 2025 um 13:11 UTCmonitoring

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

3. 22. Oktober 2025 um 13:16 UTCresolved

   The EU API has been restored.

1. 20. Oktober 2025 um 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. 20. Oktober 2025 um 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. 20. Oktober 2025 um 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. 20. Oktober 2025 um 19:58 UTCresolved

   This incident has been resolved.

1. 20. Oktober 2025 um 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. 12. Februar 2025 um 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. 22. Oktober 2024 um 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. 22. Oktober 2024 um 15:30 UTCresolved

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

1. 23. September 2024 um 10:37 UTCinvestigating

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

2. 23. September 2024 um 11:48 UTCmonitoring

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

3. 23. September 2024 um 11:57 UTCresolved

   This incident has been resolved.

1. 24. Juli 2024 um 23:42 UTCidentified

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

2. 25. Juli 2024 um 01: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. 25. Juli 2024 um 03:06 UTCresolved

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

1. 12. Februar 2024 um 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. 12. Februar 2024 um 20:39 UTCresolved

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

1. 6. Februar 2024 um 20:59 UTCinvestigating

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

2. 6. Februar 2024 um 21:02 UTCinvestigating

   We are continuing to investigate this issue.

3. 6. Februar 2024 um 21:42 UTCidentified

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

4. 6. Februar 2024 um 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. 6. Februar 2024 um 23:19 UTCresolved

   This incident has been resolved.

1. 17. Januar 2024 um 19:19 UTCidentified

   We are working on restoring service

2. 17. Januar 2024 um 19:21 UTCresolved

   This incident has been resolved.

1. 10. November 2023 um 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. 13. Juni 2023 um 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. 13. Juni 2023 um 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. 13. Juni 2023 um 21:37 UTCresolved

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

1. 25. März 2023 um 01: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. 24. März 2023 um 08:05 UTCinvestigating

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

2. 24. März 2023 um 08:40 UTCidentified

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

3. 24. März 2023 um 09: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. 9. März 2023 um 09:46 UTCresolved

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