Historial de interrupciones de Honeybadger

1. 15 de agosto de 2026 a las 20:48 UTCresolved

   Entre 19:54 y 20:07 UTC el 15 de agosto, las solicitudes a nuestra API de informes de errores de los EE.UU. (api.honeybadger.io) experimentaron una tasa de falla elevada. Durante esta ventana, la mayoría de las solicitudes para presentar errores y eventos se ordenaron o recibieron respuestas 5xx. Navegador (JavaScript) reportaje de errores, subidas de mapas de origen, aplicación web de Honeybadger, tableros de control, monitoreo de tiempo fijo y nuestra región de la UE no fueron afectados. Lo que sucedió: A partir de las 19:54 UTC, una única fuente comenzó a presentar informes de error aproximadamente 150 veces su tasa normal, con cargas de pago varias veces más grande que la media. Esto duplicó más que el volumen total de datos que llegaban a nuestro nivel de ingestión, que saturaba en un minuto. Debido a que el servicio saturado seguía aceptando conexiones en lugar de devolver errores de forma directa, nuestro autoescalamiento y alerta —que observan respuestas de error— no registraban el problema rápidamente, y la capacidad se añadió más tarde de lo que debería haber sido. Servicio recuperado a 20:07 UTC una vez que la capacidad adicional vino en línea. La mayoría de los informes afectados fueron retrigados con éxito por nuestras bibliotecas cliente cuando se recuperó la API, por lo que la gran mayoría de los datos presentados durante la ventana fue finalmente recibido. No se recibieron informes enviados por bibliotecas sin lógica de reingreso y no se pueden recuperar. Lo que hemos hecho: nuestro nivel de ingestión ahora escala latencia de respuesta además de las tasas de error, por lo que este tipo de saturación se detecta dentro de un minuto o dos en lugar de sólo una vez que aparecen errores. También hemos aumentado la capacidad de referencia del nivel y hemos ampliado nuestras alertas de paging para cubrir fallos que no superan como errores del servidor. Además, estamos añadiendo límites sobre cuántos datos puede presentar una única fuente. Lo sentimos por la interrupción, y por cualquier brecha que haya causado en sus datos de error durante la ventana.

Traducido automáticamente desde la actualización oficial del incidente.

1. 8 de julio de 2026 a las 11:48 UTCresolved

   Entre 06:22 y 08:23 UTC el 8 de julio, las solicitudes a nuestra API de informes de errores de EE.UU. (api.honeybadger.io) experimentaron una tasa de falla altamente elevada. Durante esta ventana, la mayoría de las solicitudes para presentar errores, eventos y check-ins recibieron respuestas de 5xx o fueron programadas. Los informes de error enviados por las bibliotecas clientes sin lógica de reingreso durante este período no fueron recibidos y no se pueden recuperar. La aplicación web Honeybadger, dashboards, monitoreo de tiempo de trabajo, y nuestra región de la UE no fueron afectados. Lo que sucedió: A partir de las 06:18 UTC, comenzamos a recibir informes de errores en aproximadamente el triple de nuestro volumen total de API normal. El nivel de servicio que ingiere este tráfico estaba en su nivel de capacidad de toda la noche y se saturaron. Nuestro autoescalamiento respondió, pero las métricas que se basaban en significativamente inframedido el tráfico fallido, por lo que la capacidad se añadió demasiado lentamente — la recuperación completa llegó a las 08:23 UTC cuando el escalado cogió y absorbió la carga. En función del problema, las alertas de PagerDuty no fueron disparadas para despertar a un humano debido a una malconfiguración. Lo que hemos hecho: Hemos fijado la debilidad de escalado subyacente: la capacidad de API ahora también escala directamente en las tasas de error de balanceador de carga (antes escalamos solamente a las tasas de solicitud, y que el escalado no responde lo suficientemente rápido), y hemos duplicado la capacidad máxima del nivel de ingestión. Estos cambios ya están desplegados tanto en las regiones de EE.UU. como en la UE. También estamos evaluando la adición de la tasa de ajuste por clave que limita al servicio de ingestión. Lo sentimos por la interrupción, y por cualquier brecha que haya causado en sus datos de error durante la ventana.

Traducido automáticamente desde la actualización oficial del incidente.

1. 12 de marzo de 2026 a las 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 de enero de 2026 a las 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 de enero de 2026 a las 20:48 UTCresolved

   This incident has been resolved.

1. 22 de octubre de 2025 a las 19:46 UTCidentified

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

2. 22 de octubre de 2025 a las 20:15 UTCresolved

   This incident has been resolved.

1. 22 de octubre de 2025 a las 13:09 UTCidentified

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

2. 22 de octubre de 2025 a las 13:11 UTCmonitoring

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

3. 22 de octubre de 2025 a las 13:16 UTCresolved

   The EU API has been restored.

1. 20 de octubre de 2025 a las 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 de octubre de 2025 a las 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 de octubre de 2025 a las 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 de octubre de 2025 a las 19:58 UTCresolved

   This incident has been resolved.

1. 20 de octubre de 2025 a las 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 de febrero de 2025 a las 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 de octubre de 2024 a las 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 de octubre de 2024 a las 15:30 UTCresolved

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

1. 23 de septiembre de 2024 a las 10:37 UTCinvestigating

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

2. 23 de septiembre de 2024 a las 11:48 UTCmonitoring

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

3. 23 de septiembre de 2024 a las 11:57 UTCresolved

   This incident has been resolved.

1. 24 de julio de 2024 a las 23:42 UTCidentified

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

2. 25 de julio de 2024 a las 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. 25 de julio de 2024 a las 3:06 UTCresolved

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

1. 12 de febrero de 2024 a las 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 de febrero de 2024 a las 20:39 UTCresolved

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

1. 6 de febrero de 2024 a las 20:59 UTCinvestigating

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

2. 6 de febrero de 2024 a las 21:02 UTCinvestigating

   We are continuing to investigate this issue.

3. 6 de febrero de 2024 a las 21:42 UTCidentified

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

4. 6 de febrero de 2024 a las 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 de febrero de 2024 a las 23:19 UTCresolved

   This incident has been resolved.

1. 17 de enero de 2024 a las 19:19 UTCidentified

   We are working on restoring service

2. 17 de enero de 2024 a las 19:21 UTCresolved

   This incident has been resolved.

1. 10 de noviembre de 2023 a las 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 de junio de 2023 a las 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 de junio de 2023 a las 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 de junio de 2023 a las 21:37 UTCresolved

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

1. 25 de marzo de 2023 a las 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. 24 de marzo de 2023 a las 8:05 UTCinvestigating

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

2. 24 de marzo de 2023 a las 8:40 UTCidentified

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

3. 24 de marzo de 2023 a las 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. 9 de marzo de 2023 a las 9:46 UTCresolved

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