Istoricul incidentelor Honeybadger

1. 15 august 2026 la 20:48 UTCresolved

   Între 19:54 și 20:07 UTC pe 15 august cererile noastre de eroare de raportare API (api.honeybadger.io) a avut o rată de eșec ridicată. În timpul acestei ferestre, majoritatea cererilor de depunere a erorilor și evenimentelor au expirat sau au primit răspunsuri 5xx. Raportarea erorilor browser-ului (JavaScript), încărcarea hărților sursă, aplicația web Honeybadger, tabloul de bord, monitorizarea în timp util și regiunea UE nu au fost afectate. Ce s-a întâmplat: Începând de la 19:54 UTC, o singură sursă a început să transmită rapoarte de eroare de aproximativ 150 de ori mai mari decât media, cu sarcini utile de mai multe ori mai mari decât media. Acest lucru a dublat volumul total de date care sosesc la nivelul nostru de ingestie, care saturat într-un minut. Deoarece serviciul saturate a continuat să accepte conexiuni, mai degrabă decât să se întoarcă erori pur și simplu, nostru autoscalare și alertare Serviciul recuperat la 20:07 UTC odată ce capacitatea suplimentară a venit on-line. Cele mai multe rapoarte afectate au fost rejudecate cu succes de către bibliotecile noastre client după recuperarea API, astfel încât marea majoritate a datelor transmise în timpul ferestrei a fost în cele din urmă primită. Rapoartele trimise de biblioteci fără a rejudeca logica nu au fost primite și nu pot fi recuperate. Ceea ce am făcut: nivelul nostru de ingerare acum scale pe latență de răspuns în plus față de ratele de eroare, astfel încât acest tip de saturare este detectat într-un minut sau două, mai degrabă decât o singură dată apar erori. Am ridicat, de asemenea, capacitatea de bază a nivelului și a lărgit alertele noastre paging pentru a acoperi eșecuri care nu suprafață ca erori de server. În plus, adăugăm limite cu privire la cât de multe date poate transmite o singură sursă. Ne pare rău pentru întrerupere, și pentru orice lacune acest cauzat în datele de eroare în timpul ferestrei.

Traducere automată din actualizarea oficială a incidentului.

1. 8 iulie 2026 la 11:48 UTCresolved

   Între 06:22 și 08:23 UTC pe 8 iulie, cererile noastre de eroare de raportare API (api.oneybadger.io) au avut o rată de eșec ridicată. În timpul acestei ferestre, majoritatea cererilor de a prezenta erori, evenimente și check-in-uri au primit răspunsuri 5xx sau au expirat. Rapoartele de eroare trimise de bibliotecile client fără rejudecarea logicii în această perioadă nu au fost primite și nu pot fi recuperate. Aplicația web Honeybadger, tabloul de bord, monitorizarea în timp util și regiunea UE nu au fost afectate. Ce sa întâmplat: Începând de la 06:18 UTC, am început să primim rapoarte de eroare la aproximativ triplu volumul nostru normal total API. Nivelul serviciilor care ingerează acest trafic a fost la nivelul capacității sale overnight și a devenit saturat. Autoscalare nostru a răspuns, dar indicatorii s-au bazat pe semnificativ sub-măsurat traficul eșuat, astfel capacitatea a fost adăugată mult prea lent Compus problema, alerte PagerDuty nu au fost trase pentru a trezi un om din cauza unei configurații greșite. Ceea ce am făcut: Am fixat slăbiciunea de scalare de bază: capacitatea API acum, de asemenea, scale direct pe ratele de eroare de echilibru de sarcină (în trecut am scalat doar la ratele de cerere, și că scalarea nu răspunde suficient de repede), și am dublat capacitatea maximă a nivelului de ingestie. Aceste schimbări sunt deja implementate atât în regiunile SUA, cât și în cele ale UE. De asemenea, evaluam adaugarea ratei adaptive per cheie limitand serviciul de ingestie. Ne pare rău pentru întrerupere, și pentru orice lacune acest cauzat în datele de eroare în timpul ferestrei.

Traducere automată din actualizarea oficială a incidentului.

1. 12 martie 2026 la 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 ianuarie 2026 la 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 ianuarie 2026 la 20:48 UTCresolved

   This incident has been resolved.

1. 22 octombrie 2025 la 19:46 UTCidentified

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

2. 22 octombrie 2025 la 20:15 UTCresolved

   This incident has been resolved.

1. 22 octombrie 2025 la 13:09 UTCidentified

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

2. 22 octombrie 2025 la 13:11 UTCmonitoring

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

3. 22 octombrie 2025 la 13:16 UTCresolved

   The EU API has been restored.

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

   This incident has been resolved.

1. 20 octombrie 2025 la 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 februarie 2025 la 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 octombrie 2024 la 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 octombrie 2024 la 15:30 UTCresolved

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

1. 23 septembrie 2024 la 10:37 UTCinvestigating

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

2. 23 septembrie 2024 la 11:48 UTCmonitoring

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

3. 23 septembrie 2024 la 11:57 UTCresolved

   This incident has been resolved.

1. 24 iulie 2024 la 23:42 UTCidentified

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

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

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

1. 12 februarie 2024 la 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 februarie 2024 la 20:39 UTCresolved

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

1. 6 februarie 2024 la 20:59 UTCinvestigating

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

2. 6 februarie 2024 la 21:02 UTCinvestigating

   We are continuing to investigate this issue.

3. 6 februarie 2024 la 21:42 UTCidentified

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

4. 6 februarie 2024 la 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 februarie 2024 la 23:19 UTCresolved

   This incident has been resolved.

1. 17 ianuarie 2024 la 19:19 UTCidentified

   We are working on restoring service

2. 17 ianuarie 2024 la 19:21 UTCresolved

   This incident has been resolved.

1. 10 noiembrie 2023 la 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 iunie 2023 la 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 iunie 2023 la 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 iunie 2023 la 21:37 UTCresolved

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

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

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

2. 24 martie 2023 la 08:40 UTCidentified

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

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

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