Cronologia delle interruzioni di Honeybadger

1. 15 agosto 2026 alle ore 20:48 UTCresolved

   Tra le 19:54 e le 20:07 UTC il 15 agosto, le richieste alla nostra API di segnalazione degli errori degli Stati Uniti (api.honeybadger.io) hanno sperimentato un tasso di guasto elevato. Durante questa finestra, la maggior parte delle richieste di inviare errori ed eventi tempestivi o ricevuti 5xx risposte. Browser (JavaScript) segnalazione di errori, upload di mappe di origine, l'applicazione web Honeybadger, dashboard, monitoraggio uptime e la nostra regione UE non sono stati colpiti. Che cosa è successo: A partire dalle 19:54 UTC, una singola fonte ha iniziato a presentare rapporti di errore a circa 150 volte il suo tasso normale, con i carichi di pagamento più volte più grandi della media. Questo più che raddoppiato il volume totale di dati che arrivano al nostro livello di ingestione, che ha saturato entro un minuto. Poiché il servizio saturato continuava ad accettare le connessioni piuttosto che restituire gli errori outright, il nostro autoscaling e l'avviso — che guardano per le risposte di errore — non ha registrato il problema rapidamente, e la capacità è stata aggiunta più tardi di quanto avrebbe dovuto essere. Servizio recuperato a 20:07 UTC una volta supplementare capacità è venuto online. La maggior parte dei report interessati sono stati riattivati con successo dalle nostre librerie client una volta recuperata l'API, quindi la grande maggioranza dei dati inviati durante la finestra è stata infine ricevuta. I rapporti inviati da biblioteche senza riprova logica non sono stati ricevuti e non possono essere recuperati. Quello che abbiamo fatto: il nostro livello di ingestione ora scala sulla latenza di risposta oltre ai tassi di errore, in modo che questo tipo di saturazione viene rilevato entro un minuto o due piuttosto che solo una volta che gli errori appaiono. Abbiamo anche aumentato la capacità di base del livello e ampliato i nostri avvisi di paging per coprire i guasti che non emergono come errori del server. Stiamo inoltre aggiungendo limiti su quanto dati un'unica fonte può presentare. Ci dispiace per l'interruzione, e per eventuali lacune che questo ha causato nei dati di errore durante la finestra.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 8 luglio 2026 alle ore 11:48 UTCresolved

   Tra le 06:22 e le 08:23 UTC l'8 luglio, le richieste alla nostra API di segnalazione di errori degli Stati Uniti (api.honeybadger.io) hanno sperimentato un tasso di guasto altamente elevato. Durante questa finestra, la maggior parte delle richieste di inviare errori, eventi e check-in ha ricevuto 5xx risposte o timed out. I rapporti di errore inviati da librerie client senza riprova logica durante questo periodo non sono stati ricevuti e non possono essere recuperati. L'applicazione web di Honeybadger, cruscotti, monitoraggio dei tempi e la nostra regione dell'UE non sono stati colpiti. Che cosa è successo: A partire dal 06:18 UTC, abbiamo iniziato a ricevere rapporti di errore a circa triplicare il nostro normale volume API totale. Il livello di servizio che ingerisce questo traffico era al suo livello di capacità notturna e divenne saturo. La nostra autoscaling ha risposto, ma le metriche si è basato su significativamente sotto-measured il traffico fallito, quindi la capacità è stata aggiunta troppo lentamente — il recupero completo è venuto alle 08:23 UTC quando scaling catturato e assorbito il carico. Completando il problema, PagerDuty avvisi non sono stati licenziati per svegliare un umano a causa di una cattiva configurazione. Quello che abbiamo fatto: Abbiamo fissato la debolezza di scaling sottostante: la capacità API ora scala anche direttamente sui tassi di errore di load-balancer (precedentemente abbiamo scalato solo sui tassi di richiesta, e che lo scaling non risponde abbastanza rapidamente), e abbiamo raddoppiato la capacità massima del livello di ingestione. Questi cambiamenti sono già dispiegati sia nelle regioni degli Stati Uniti che nell'UE. Stiamo anche valutando l'aggiunta di tasso adattativo per chiave limitante al servizio di ingestione. Ci dispiace per l'interruzione, e per eventuali lacune che questo ha causato nei dati di errore durante la finestra.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 12 marzo 2026 alle ore 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 gennaio 2026 alle ore 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 gennaio 2026 alle ore 20:48 UTCresolved

   This incident has been resolved.

1. 22 ottobre 2025 alle ore 19:46 UTCidentified

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

2. 22 ottobre 2025 alle ore 20:15 UTCresolved

   This incident has been resolved.

1. 22 ottobre 2025 alle ore 13:09 UTCidentified

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

2. 22 ottobre 2025 alle ore 13:11 UTCmonitoring

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

3. 22 ottobre 2025 alle ore 13:16 UTCresolved

   The EU API has been restored.

1. 20 ottobre 2025 alle ore 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 ottobre 2025 alle ore 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 ottobre 2025 alle ore 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 ottobre 2025 alle ore 19:58 UTCresolved

   This incident has been resolved.

1. 20 ottobre 2025 alle ore 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 febbraio 2025 alle ore 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 ottobre 2024 alle ore 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 ottobre 2024 alle ore 15:30 UTCresolved

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

1. 23 settembre 2024 alle ore 10:37 UTCinvestigating

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

2. 23 settembre 2024 alle ore 11:48 UTCmonitoring

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

3. 23 settembre 2024 alle ore 11:57 UTCresolved

   This incident has been resolved.

1. 24 luglio 2024 alle ore 23:42 UTCidentified

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

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

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

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

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

1. 6 febbraio 2024 alle ore 20:59 UTCinvestigating

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

2. 6 febbraio 2024 alle ore 21:02 UTCinvestigating

   We are continuing to investigate this issue.

3. 6 febbraio 2024 alle ore 21:42 UTCidentified

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

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

   This incident has been resolved.

1. 17 gennaio 2024 alle ore 19:19 UTCidentified

   We are working on restoring service

2. 17 gennaio 2024 alle ore 19:21 UTCresolved

   This incident has been resolved.

1. 10 novembre 2023 alle ore 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 giugno 2023 alle ore 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 giugno 2023 alle ore 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 giugno 2023 alle ore 21:37 UTCresolved

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

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

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

2. 24 marzo 2023 alle ore 08:40 UTCidentified

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

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

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