История сбоев Honeybadger

1. 15 августа 2026 г. в 20:48 UTCresolved

   В период между 19:54 и 20:07 UTC 15 августа запросы на наш API отчетности об ошибках в США (api.honeybadger.io) имели повышенный уровень отказов. Во время этого окна большинство запросов на отправку ошибок и событий отсчитываются или получают ответы 5xx. Отчеты об ошибках браузера (JavaScript), загрузка исходных карт, веб-приложение Honeybadger, панели инструментов, мониторинг времени безотказной работы и наш регион ЕС не пострадали. Начиная с 19:54 UTC, один источник начал отправлять отчеты об ошибках примерно в 150 раз чаще, чем обычно, с полезной нагрузкой в несколько раз больше, чем в среднем. Это более чем удвоило общий объем данных, поступающих на наш уровень потребления, который насыщался в течение минуты. Поскольку насыщенная служба продолжала принимать соединения, а не сразу возвращать ошибки, наша автоматизация и оповещение, которые следят за ответами на ошибки, не регистрировали проблему быстро, и емкость была добавлена позже, чем должна была быть. Сервис восстановился в 20:07 UTC после того, как появилась дополнительная емкость. Большинство затронутых отчетов были успешно проверены нашими клиентскими библиотеками после восстановления API, поэтому большая часть данных, представленных во время окна, была в конечном итоге получена. Отчеты, отправленные библиотеками без логической проверки, не были получены и не могут быть восстановлены. То, что мы сделали: наш уровень приема пищи теперь масштабируется на задержку ответа в дополнение к частоте ошибок, поэтому этот вид насыщения обнаруживается в течение минуты или двух, а не только после появления ошибок. Мы также увеличили базовую емкость яруса и расширили наши оповещения о подаче, чтобы покрыть сбои, которые не проявляются как ошибки сервера. Мы также добавляем ограничения на количество данных, которые может предоставить один источник. Мы сожалеем о сбое и о любых пробелах, вызванных вашими данными об ошибках во время окна.

Автоматический перевод официального обновления инцидента.

1. 8 июля 2026 г. в 11:48 UTCresolved

   В период с 06:22 по 08:23 UTC 8 июля запросы на наш API отчетности об ошибках в США (api.honeybadger.io) имели очень высокий уровень отказов. Во время этого окна большинство запросов на отправку ошибок, событий и заездов получили 5xx ответов или были отсрочены. Отчёты об ошибках, отправленные библиотеками-клиентами без логики повторного использования в течение этого периода, не были получены и не могут быть восстановлены. Веб-приложение Honeybadger, информационные панели, мониторинг времени безотказной работы и наш регион ЕС не пострадали. Начиная с 06:18 UTC, мы начали получать отчеты об ошибках примерно в три раза больше обычного общего объема API. Уровень обслуживания, который поглощает этот трафик, был на уровне пропускной способности и стал насыщенным. Наше автомасштабирование ответило, но показатели, на которые оно опиралось, значительно недооценили неисправный трафик, поэтому пропускная способность была добавлена слишком медленно — полное восстановление произошло в 08:23 UTC, когда масштабирование догнало и поглощало нагрузку. Усугубляя проблему, предупреждения PagerDuty не были выпущены, чтобы разбудить человека из-за неправильной конфигурации. Мы исправили основную слабость масштабирования: емкость API теперь также масштабируется непосредственно на частоту ошибок балансировки нагрузки (ранее мы масштабировались только на частоту запросов, и это масштабирование не реагирует достаточно быстро), и мы удвоили максимальную емкость уровня приема пищи. Эти изменения уже развернуты в регионах США и ЕС. Мы также оцениваем добавление адаптивной ставки за ключ, ограничивающей прием пищи. Мы сожалеем о сбое и о любых пробелах, вызванных вашими данными об ошибках во время окна.

Автоматический перевод официального обновления инцидента.

1. 12 марта 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 января 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 января 2026 г. в 20:48 UTCresolved

   This incident has been resolved.

1. 22 октября 2025 г. в 19:46 UTCidentified

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

2. 22 октября 2025 г. в 20:15 UTCresolved

   This incident has been resolved.

1. 22 октября 2025 г. в 13:09 UTCidentified

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

2. 22 октября 2025 г. в 13:11 UTCmonitoring

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

3. 22 октября 2025 г. в 13:16 UTCresolved

   The EU API has been restored.

1. 20 октября 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 октября 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 октября 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 октября 2025 г. в 19:58 UTCresolved

   This incident has been resolved.

1. 20 октября 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 февраля 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 октября 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 октября 2024 г. в 15:30 UTCresolved

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

1. 23 сентября 2024 г. в 10:37 UTCinvestigating

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

2. 23 сентября 2024 г. в 11:48 UTCmonitoring

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

3. 23 сентября 2024 г. в 11:57 UTCresolved

   This incident has been resolved.

1. 24 июля 2024 г. в 23:42 UTCidentified

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

2. 25 июля 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 июля 2024 г. в 03:06 UTCresolved

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

1. 12 февраля 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 февраля 2024 г. в 20:39 UTCresolved

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

1. 6 февраля 2024 г. в 20:59 UTCinvestigating

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

2. 6 февраля 2024 г. в 21:02 UTCinvestigating

   We are continuing to investigate this issue.

3. 6 февраля 2024 г. в 21:42 UTCidentified

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

4. 6 февраля 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 февраля 2024 г. в 23:19 UTCresolved

   This incident has been resolved.

1. 17 января 2024 г. в 19:19 UTCidentified

   We are working on restoring service

2. 17 января 2024 г. в 19:21 UTCresolved

   This incident has been resolved.

1. 10 ноября 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 июня 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 июня 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 июня 2023 г. в 21:37 UTCresolved

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

1. 25 марта 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 марта 2023 г. в 08:05 UTCinvestigating

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

2. 24 марта 2023 г. в 08:40 UTCidentified

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

3. 24 марта 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 марта 2023 г. в 09:46 UTCresolved

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