Honeybadger Outage History
Honeybadger is up right nowPingoru has recorded 52 incidents for Honeybadger: 4 in the last 12 months and 1 in the last 90 days.
Show as a table
| Month | Incidents | Hours with an open incident |
|---|---|---|
| April 2026 | 0 | 0 of 720 (0%) |
| May 2026 | 0 | 0 of 744 (0%) |
| June 2026 | 0 | 0 of 720 (0%) |
| July 2026 | 1 | 2 of 744 (0%) |
| August 2026 | 1 | 0 of 744 (0%) |
| September 2026 | 0 | 0 of 720 (0%) |
| October 2026 | 0 | 0 of 528 (0%) |
Incidents, newest first
Notice August 15, 2026 Elevated failure rates on the US error reporting API 13m API
Started Aug 15, 2026, 07:54 PM UTC· resolved Aug 15, 2026, 08:07 PM UTC
- resolved Aug 15, 2026, 08:48 PM UTC
Between 19:54 and 20:07 UTC on August 15, requests to our US error reporting API (api.honeybadger.io) experienced an elevated failure rate. During this window, a majority of requests to submit errors and events timed out or received 5xx responses. Browser (JavaScript) error reporting, source map uploads, the Honeybadger web application, dashboards, uptime monitoring, and our EU region were not affected. What happened: Beginning at 19:54 UTC, a single source began submitting error reports at roughly 150 times its normal rate, with payloads several times larger than average. This more than doubled the total volume of data arriving at our ingestion tier, which saturated within a minute. Because the saturated service kept accepting connections rather than returning errors outright, our autoscaling and alerting — which watch for error responses — did not register the problem quickly, and capacity was added later than it should have been. Service recovered at 20:07 UTC once additional capacity came online. Most affected reports were retried successfully by our client libraries once the API recovered, so the large majority of data submitted during the window was ultimately received. Reports sent by libraries without retry logic were not received and cannot be recovered. What we've done: our ingestion tier now scales on response latency in addition to error rates, so this kind of saturation is detected within a minute or two rather than only once errors appear. We've also raised the tier's baseline capacity and widened our paging alerts to cover failures that don't surface as server errors. We're additionally adding limits on how much data a single source can submit. We're sorry for the disruption, and for any gaps this caused in your error data during the window.
Major July 8, 2026 Elevated error rates on the US error reporting API 2h 1m API
Started Jul 08, 2026, 06:22 AM UTC· resolved Jul 08, 2026, 08:23 AM UTC
- resolved Jul 08, 2026, 11:48 AM UTC
Between 06:22 and 08:23 UTC on July 8, requests to our US error reporting API (api.honeybadger.io) experienced a highly elevated failure rate. During this window, a majority of requests to submit errors, events, and check-ins received 5xx responses or timed out. Error reports sent by client libraries without retry logic during this period were not received and cannot be recovered. The Honeybadger web application, dashboards, uptime monitoring, and our EU region were not affected. What happened: Beginning at 06:18 UTC, we started receiving error reports at roughly triple our normal total API volume. The service tier that ingests this traffic was at its overnight capacity level and became saturated. Our autoscaling responded, but the metrics it relied on significantly under-measured the failed traffic, so capacity was added far too slowly — full recovery came at 08:23 UTC when scaling caught up and absorbed the load. Compounding the problem, PagerDuty alerts were not fired to wake up a human due to a misconfiguration. What we've done: We've fixed the underlying scaling weakness: API capacity now also scales directly on load-balancer error rates (previously we scaled only on request rates, and that scaling doesn't respond quickly enough), and we've doubled the maximum capacity of the ingestion tier. These changes are already deployed to both US and EU regions. We're also evaluating adding adaptive per-key rate limiting to the ingestion service. We're sorry for the disruption, and for any gaps this caused in your error data during the window.
Minor March 12, 2026 Delays with notifications –
Started Mar 12, 2026, 07:27 PM UTC· resolved Mar 12, 2026, 07:27 PM UTC
- resolved Mar 12, 2026, 07:27 PM UTC
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.
Major January 14, 2026 Outage in check-in processing 7m API
Started Jan 14, 2026, 08:40 PM UTC· resolved Jan 14, 2026, 08:48 PM UTC
- identified Jan 14, 2026, 08:40 PM UTC
A recent deploy has resulted in our rejecting some check-in API requests. We are in the process of deploying a fix.
- resolved Jan 14, 2026, 08:48 PM UTC
This incident has been resolved.
Major October 22, 2025 Insights queries and dashboards are unavailable 28m Web Application
Started Oct 22, 2025, 07:46 PM UTC· resolved Oct 22, 2025, 08:15 PM UTC
- identified Oct 22, 2025, 07:46 PM UTC
The issue has been identified and a fix is being implemented.
- resolved Oct 22, 2025, 08:15 PM UTC
This incident has been resolved.
Critical October 22, 2025 Error ingestion API is down 6m API
Started Oct 22, 2025, 01:09 PM UTC· resolved Oct 22, 2025, 01:16 PM UTC
- identified Oct 22, 2025, 01:09 PM UTC
API ingestion of errors has been interrupted. We are deploying a fix.
- monitoring Oct 22, 2025, 01:11 PM UTC
The US API has been restored, and the EU API restoration is in process.
- resolved Oct 22, 2025, 01:16 PM UTC
The EU API has been restored.
Notice October 20, 2025 Delays in error processing 6h 14m API
Started Oct 20, 2025, 01:44 PM UTC· resolved Oct 20, 2025, 07:58 PM UTC
- identified Oct 20, 2025, 01:44 PM UTC
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.
- identified Oct 20, 2025, 05:55 PM UTC
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.
- monitoring Oct 20, 2025, 07:58 PM UTC
Processing has been restored and all systems are normal. We'll continue to monitor as AWS continues to restore service. Thanks!
- resolved Oct 20, 2025, 07:58 PM UTC
This incident has been resolved.
Major October 20, 2025 AWS outage in us-east-1 –
Started Oct 20, 2025, 08:00 AM UTC· resolved Oct 20, 2025, 08:00 AM UTC
- resolved Oct 20, 2025, 01:36 PM UTC
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.
Minor February 12, 2025 Delay in stats and check-in processing 1h Web Application, Slack Notifications
Started Feb 12, 2025, 12:30 PM UTC· resolved Feb 12, 2025, 01:30 PM UTC
- resolved Feb 12, 2025, 01:45 PM UTC
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.