Historia awarii Honeybadger

1. 15 sierpnia 2026 20:48 UTCresolved

   Między 19: 54 a 20: 07 UTC 15 sierpnia, prośby do naszego amerykańskiego raportowania błędów API (api.honedbadger.io) doświadczyły zwiększonego wskaźnika awarii. W tym oknie większość wniosków o złożenie błędów i zdarzeń została rozpatrzona w czasie lub otrzymała odpowiedzi 5xx. Przeglądarka (JavaScript) zgłaszania błędów, wysyłania map źródłowych, aplikacji internetowej Honeybadger, tablic rozdzielczych, monitorowania czasu pracy i naszego regionu UE nie zostały naruszone. Co się stało: Począwszy od 19: 54 UTC, pojedyncze źródło zaczęło składać raporty błędów z około 150 razy większą prędkością niż średnia. To ponad dwukrotnie więcej niż całkowita ilość danych przybywających do naszego poziomu spożycia, które nasycone w ciągu minuty. Ponieważ nasycona usługa akceptowała połączenia zamiast bezpośrednio zwracać błędy, nasze autoskalowanie i ostrzeganie - które obserwują odpowiedzi błędów - nie rejestruje problemu szybko, a pojemność została dodana później niż powinna. Usługa odzyskana o godzinie 20: 07 UTC po uruchomieniu dodatkowej przepustowości. Większość z nich została ponownie sprawdzona przez biblioteki naszych klientów po odzyskaniu API, więc znaczna większość danych przekazanych podczas okna została ostatecznie odebrana. Nie otrzymano raportów wysłanych przez biblioteki bez ponownego sprawdzenia logiki i nie można ich odzyskać. To, co zrobiliśmy: nasz poziom spożycia teraz skaluje się na opóźnieniu reakcji, oprócz poziomu błędów, więc ten rodzaj nasycenia jest wykrywany w ciągu minuty lub dwóch zamiast tylko raz pojawiają się błędy. Zwiększyliśmy również pojemność wyjściową poziomu i rozszerzyliśmy nasze alarmy wzywania, aby pokryć awarie, które nie pojawiają się jako błędy serwera. Dodatkowo dodajemy ograniczenia co do ilości danych, jakie może dostarczyć pojedyncze źródło. Przepraszamy za zakłócenia i za wszelkie luki w danych o błędach w oknie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 8 lipca 2026 11:48 UTCresolved

   Między 06: 22 a 08: 23 UTC w dniu 8 lipca, prośby do naszego amerykańskiego raportowania błędów API (api.honedbadger.io) doświadczyły bardzo wysokiego wskaźnika awarii. Podczas tego okna większość żądań składania błędów, zdarzeń i check- ins otrzymała odpowiedzi 5xx lub została wyłączona. W tym okresie nie otrzymano raportów o błędach wysłanych przez biblioteki klientów bez powtórzenia logiki i nie można ich odzyskać. Aplikacja internetowa Honeybadger, tablice rozdzielcze, monitoring czasu pracy oraz nasz region UE nie zostały naruszone. Co się stało: Począwszy od 06: 18 UTC, zaczęliśmy otrzymywać raporty o błędach w przybliżeniu trzykrotnym naszym normalnym woluminie API. Poziom obsługi, który pochłania ten ruch był na jego poziomie pojemności overnight i stał się nasycony. Nasza autoskalowanie odpowiedziało, ale wskaźniki, na których oparła się, znacznie za słabo mierzyły nieudany ruch, więc wydajność została dodana o wiele za wolno - pełne odzyskanie nastąpiło o 08: 23 UTC, kiedy skalowanie złapało i wchłonęło ładunek. Włączając problem, alarmy PagerDuty nie zostały wystrzelone, aby obudzić człowieka z powodu niewłaściwej konfiguracji. To, co zrobiliśmy: Naprawiliśmy leżącą u podstaw słabość skalowania: Zdolność API teraz również skaluje się bezpośrednio na poziomie błędu load- balancer (wcześniej skalowaliśmy tylko na poziomie zapotrzebowania, a skalowanie nie reaguje wystarczająco szybko) i podwoiliśmy maksymalną pojemność poziomu spożycia. Zmiany te są już stosowane zarówno w regionach USA, jak i UE. Oceniamy również dodawanie przystosowawczej stawki per-key ograniczającej do usługi spożywania. Przepraszamy za zakłócenia i za wszelkie luki w danych o błędach w oknie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 12 marca 2026 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 stycznia 2026 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 stycznia 2026 20:48 UTCresolved

   This incident has been resolved.

1. 22 października 2025 19:46 UTCidentified

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

2. 22 października 2025 20:15 UTCresolved

   This incident has been resolved.

1. 22 października 2025 13:09 UTCidentified

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

2. 22 października 2025 13:11 UTCmonitoring

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

3. 22 października 2025 13:16 UTCresolved

   The EU API has been restored.

1. 20 października 2025 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 października 2025 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 października 2025 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 października 2025 19:58 UTCresolved

   This incident has been resolved.

1. 20 października 2025 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 lutego 2025 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 października 2024 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 października 2024 15:30 UTCresolved

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

1. 23 września 2024 10:37 UTCinvestigating

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

2. 23 września 2024 11:48 UTCmonitoring

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

3. 23 września 2024 11:57 UTCresolved

   This incident has been resolved.

1. 24 lipca 2024 23:42 UTCidentified

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

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

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

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

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

1. 6 lutego 2024 20:59 UTCinvestigating

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

2. 6 lutego 2024 21:02 UTCinvestigating

   We are continuing to investigate this issue.

3. 6 lutego 2024 21:42 UTCidentified

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

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

   This incident has been resolved.

1. 17 stycznia 2024 19:19 UTCidentified

   We are working on restoring service

2. 17 stycznia 2024 19:21 UTCresolved

   This incident has been resolved.

1. 10 listopada 2023 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 czerwca 2023 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 czerwca 2023 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 czerwca 2023 21:37 UTCresolved

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

1. 25 marca 2023 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 marca 2023 08:05 UTCinvestigating

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

2. 24 marca 2023 08:40 UTCidentified

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

3. 24 marca 2023 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 marca 2023 09:46 UTCresolved

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