Historique des pannes de Honeybadger

1. 15 août 2026 à 20:48 UTCresolved

   Entre 19:54 et 20:07 UTC le 15 août, les demandes à notre API américaine de déclaration d'erreurs (api.honeybadger.io) ont connu un taux d'échec élevé. Au cours de cette fenêtre, la majorité des demandes de soumission d'erreurs et d'événements ont été reportées ou ont reçu 5xx réponses. Les rapports d'erreurs du navigateur (JavaScript), les téléchargements de cartes sources, l'application web Honeybadger, les tableaux de bord, la surveillance des heures de pointe et notre région de l'UE n'ont pas été touchés. Ce qui s'est passé : À partir de 19h54 UTC, une source unique a commencé à soumettre des rapports d'erreurs à environ 150 fois son taux normal, avec des charges utiles plusieurs fois plus grandes que la moyenne. Cela a plus que doublé le volume total de données arrivant à notre niveau d'ingestion, qui a saturé en une minute. Comme le service saturé n'arrêtait pas d'accepter des connexions plutôt que de renvoyer des erreurs, notre auto-scalage et notre alerte — qui surveillent les réponses aux erreurs — n'ont pas enregistré le problème rapidement, et la capacité a été ajoutée plus tard qu'elle n'aurait dû l'être. Service récupéré à 20:07 UTC une fois la capacité supplémentaire est venu en ligne. La plupart des rapports touchés ont été récupérés avec succès par nos bibliothèques clientes une fois l'API récupérée, de sorte que la grande majorité des données soumises pendant la fenêtre a finalement été reçue. Les rapports envoyés par les bibliothèques sans logique de réessayer n'ont pas été reçus et ne peuvent pas être récupérés. Ce que nous avons fait : notre niveau d'ingestion augmente maintenant la latence de réponse en plus des taux d'erreur, donc ce type de saturation est détecté en une minute ou deux plutôt qu'une seule fois. Nous avons également augmenté la capacité de base du niveau et élargi nos alertes de téléappel pour couvrir les défaillances qui ne font pas surface en tant qu'erreurs de serveur. Nous ajoutons également des limites sur la quantité de données qu'une seule source peut soumettre. Nous sommes désolés pour la perturbation, et pour les lacunes que cela a causé dans vos données d'erreur pendant la fenêtre.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 8 juillet 2026 à 11:48 UTCresolved

   Entre 06:22 et 08:23 UTC le 8 juillet, les demandes à notre API américaine de déclaration d'erreurs (api.honeybadger.io) ont connu un taux de défaillance très élevé. Au cours de cette fenêtre, la majorité des demandes d'erreurs, d'événements et d'enregistrements ont reçu 5xx réponses ou ont été reportées. Les rapports d'erreur envoyés par les bibliothèques clientes sans logique de réessayer pendant cette période n'ont pas été reçus et ne peuvent pas être récupérés. L'application web Honeybadger, les tableaux de bord, la surveillance des heures de pointe et notre région de l'UE n'ont pas été touchés. Ce qui s'est passé: À partir de 06:18 UTC, nous avons commencé à recevoir des rapports d'erreurs à peu près tripler notre volume d'API total normal. Le niveau de service qui ingère ce trafic était à sa capacité de nuit et est devenu saturé. Notre étalonnage automatique a répondu, mais les mesures sur lesquelles il s'est appuyé étaient nettement sous-mesurées le trafic échoué, de sorte que la capacité a été ajoutée beaucoup trop lentement — la pleine récupération est venue à 08:23 UTC lorsque l'échelle a pris et absorbé la charge. Complétant le problème, les alertes de PagerDuty n'ont pas été lancées pour réveiller un humain en raison d'une erreur de configuration. Ce que nous avons fait : Nous avons corrigé la faiblesse de l'échelle sous-jacente : la capacité de l'API s'échelle maintenant directement sur les taux d'erreur de l'équilibreur de charge (auparavant, nous n'évaluions que sur les taux de demande, et cette échelle ne répond pas assez rapidement), et nous avons doublé la capacité maximale du niveau d'ingestion. Ces changements sont déjà déployés dans les régions des États-Unis et de l'UE. Nous évaluons également l'ajout d'un taux adaptatif par clé limitant le service d'ingestion. Nous sommes désolés pour la perturbation, et pour les lacunes que cela a causé dans vos données d'erreur pendant la fenêtre.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 12 mars 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 janvier 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 janvier 2026 à 20:48 UTCresolved

   This incident has been resolved.

1. 22 octobre 2025 à 19:46 UTCidentified

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

2. 22 octobre 2025 à 20:15 UTCresolved

   This incident has been resolved.

1. 22 octobre 2025 à 13:09 UTCidentified

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

2. 22 octobre 2025 à 13:11 UTCmonitoring

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

3. 22 octobre 2025 à 13:16 UTCresolved

   The EU API has been restored.

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

   This incident has been resolved.

1. 20 octobre 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 février 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 octobre 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 octobre 2024 à 15:30 UTCresolved

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

1. 23 septembre 2024 à 10:37 UTCinvestigating

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

2. 23 septembre 2024 à 11:48 UTCmonitoring

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

3. 23 septembre 2024 à 11:57 UTCresolved

   This incident has been resolved.

1. 24 juillet 2024 à 23:42 UTCidentified

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

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

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

1. 12 février 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 février 2024 à 20:39 UTCresolved

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

1. 6 février 2024 à 20:59 UTCinvestigating

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

2. 6 février 2024 à 21:02 UTCinvestigating

   We are continuing to investigate this issue.

3. 6 février 2024 à 21:42 UTCidentified

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

4. 6 février 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 février 2024 à 23:19 UTCresolved

   This incident has been resolved.

1. 17 janvier 2024 à 19:19 UTCidentified

   We are working on restoring service

2. 17 janvier 2024 à 19:21 UTCresolved

   This incident has been resolved.

1. 10 novembre 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 juin 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 juin 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 juin 2023 à 21:37 UTCresolved

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

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

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

2. 24 mars 2023 à 08:40 UTCidentified

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

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

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