Honeybadger 장애 기록

1. 2026년 8월 15일 PM 8:48 UTCresolved

   19:54 과 20:07 UTC 에 8월 15, 우리의 미국 오류 보고 API (api.honeybadger.io) 높은 실패율을 경험. 이 창에서 오류 및 이벤트를 제출하거나 5xx 응답을 받았다. 브라우저 (JavaScript) 오류 보고, 소스 맵 업로드, Honeybadger 웹 응용 프로그램, 대시보드, 가동 시간 모니터링, 우리의 EU 지역 영향을받지 않았습니다. 무슨 일이: 19:54 UTC에서 시작, 단일 소스는 평균보다 더 큰 급여와 함께 약 150 배의 정상적인 비율에 오류 보고서를 제출 시작. 이 데이터의 총 부피가 1 분 이내에 포화 된 우리의 섭취 계층에 도착했습니다. 포화 서비스로 인해 오류가 발생하지 않고 연결을 허용하기 때문에, 자동 확장 및 경고 - 오류 응답을 볼 - 신속하게 문제를 등록하지 않았다, 용량은 나중에 추가되었다. 서비스 복구 20:07 UTC 한 번 추가 용량은 온라인으로왔다. 대부분의 영향을받는 보고서는 API 복구를 한 번 우리의 클라이언트 라이브러리에 의해 성공적으로 복원되었습니다, 그래서 창에 제출 된 많은 데이터는 궁극적으로 수신되었습니다. 리트리 논리없이 라이브러리에 의해 전송 된 보고서는받지 않고 복구 할 수 없습니다. 우리가 수행 한 일 : 우리의 섭취 계층은 이제 오류율 이외에 응답 지연에 대한 스케일을 스케일링합니다. 따라서 포화의이 종류는 한 번만 오류가 나타났습니다. 우리는 또한 계층의 기본 용량을 제기하고 서버 오류로 표면이없는 실패를 커버하는 우리의 paging 경고를 폭 넓은. 단일 소스가 제출할 수 있는 방법에 대한 제한을 추가합니다. 우리는 혼란에 대해 죄송합니다. 창에서 오류 데이터에 발생하지 않은 간격.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 8일 AM 11:48 UTCresolved

   사이 06:22 그리고 08:23 UTC 에 7월 8, 우리의 미국 오류 보고 API (api.honeybadger.io) 매우 높은 실패율을 경험. 이 창에서, 대부분의 요청은 오류, 이벤트를 제출하고 체크 인은 5xx 응답을 받거나 중단했습니다. 이 기간 동안 재량 논리 없이 클라이언트 라이브러리에 의해 보낸 오류 보고서는 수신되지 않았고 복구 할 수 없습니다. Honeybadger 웹 응용 프로그램, 대시보드, 가동 시간 모니터링 및 우리의 EU 지역은 영향을받지 않았습니다. 무슨 일이: 06:18 UTC에 시작, 우리는 대략 3배 우리의 정상적인 총 API 양에 오류 보고를 받기 시작했습니다. 이 트래픽은 밤새의 용량 수준에 영향을 미치는 서비스 계층은 포화되었다. 우리의 오토 스케일링 응답, 하지만 메트릭은 실패 트래픽을 크게 측정에 의존, 그래서 용량은 너무 천천히 추가되었다 - 전체 복구에왔다 08:23 UTC 흩어지고 부하를 흡수 할 때. 문제 합성, PagerDuty alerts는 잘못 구성으로 인해 인간을 깨지 못했습니다. 우리가 수행 한 것은 무엇입니까 : 우리는 아래 흩어지기 약점을 고정했습니다 : API 용량은 이제로드 밸런서 오류율에 직접 스케일을 (이전 우리는 요청 요금에만 스케일링하고 그 스케일링은 충분히 신속하게 반응하지 않습니다), 우리는 섭취 계층의 최대 용량을 두 배로했습니다. 이러한 변화는 이미 미국과 EU 지역에서 배포됩니다. 우리는 또한 ingestion 서비스에 제한하는 1 키 비율을 추가 evaluating. 우리는 혼란에 대해 죄송합니다. 창에서 오류 데이터에 발생하지 않은 간격.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 3월 12일 PM 7: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. 2026년 1월 14일 PM 8: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. 2026년 1월 14일 PM 8:48 UTCresolved

   This incident has been resolved.

1. 2025년 10월 22일 PM 7:46 UTCidentified

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

2. 2025년 10월 22일 PM 8:15 UTCresolved

   This incident has been resolved.

1. 2025년 10월 22일 PM 1:09 UTCidentified

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

2. 2025년 10월 22일 PM 1:11 UTCmonitoring

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

3. 2025년 10월 22일 PM 1:16 UTCresolved

   The EU API has been restored.

1. 2025년 10월 20일 PM 1: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. 2025년 10월 20일 PM 5: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. 2025년 10월 20일 PM 7:58 UTCmonitoring

   Processing has been restored and all systems are normal. We'll continue to monitor as AWS continues to restore service. Thanks!

4. 2025년 10월 20일 PM 7:58 UTCresolved

   This incident has been resolved.

1. 2025년 10월 20일 PM 1: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. 2025년 2월 12일 PM 1: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. 2024년 10월 22일 PM 1: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. 2024년 10월 22일 PM 3:30 UTCresolved

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

1. 2024년 9월 23일 AM 10:37 UTCinvestigating

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

2. 2024년 9월 23일 AM 11:48 UTCmonitoring

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

3. 2024년 9월 23일 AM 11:57 UTCresolved

   This incident has been resolved.

1. 2024년 7월 24일 PM 11:42 UTCidentified

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

2. 2024년 7월 25일 AM 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. 2024년 7월 25일 AM 3:06 UTCresolved

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

1. 2024년 2월 12일 PM 8: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. 2024년 2월 12일 PM 8:39 UTCresolved

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

1. 2024년 2월 6일 PM 8:59 UTCinvestigating

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

2. 2024년 2월 6일 PM 9:02 UTCinvestigating

   We are continuing to investigate this issue.

3. 2024년 2월 6일 PM 9:42 UTCidentified

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

4. 2024년 2월 6일 PM 11: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. 2024년 2월 6일 PM 11:19 UTCresolved

   This incident has been resolved.

1. 2024년 1월 17일 PM 7:19 UTCidentified

   We are working on restoring service

2. 2024년 1월 17일 PM 7:21 UTCresolved

   This incident has been resolved.

1. 2023년 11월 10일 PM 7: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. 2023년 6월 13일 PM 6: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. 2023년 6월 13일 PM 7: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. 2023년 6월 13일 PM 9:37 UTCresolved

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

1. 2023년 3월 25일 AM 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. 2023년 3월 24일 AM 8:05 UTCinvestigating

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

2. 2023년 3월 24일 AM 8:40 UTCidentified

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

3. 2023년 3월 24일 AM 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. 2023년 3월 9일 AM 9:46 UTCresolved

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