Delayed error processing and missed alerts (US region)
Between 13:38 and 13:45 UTC on November 7, during planned maintenance on one of our Redis servers, part of our error-processing pipeline failed after the server switched to its upgraded node. Processing of incoming errors in the US region was delayed by up to about six minutes. No error data was lost: every error report we received was stored. For roughly 1,900 error reports received between 13:38 and 13:41 UTC, some follow-up steps did not run. As a result, you may not have received an alert for a new error first seen in that window, and a resolved error that recurred in that window may not have been automatically reopened. Some of these occurrences may also appear more than once in search results and occurrence counts. The issue has been resolved and processing has been normal since 13:45 UTC. We are working on fixing the alerts and duplicate occurrences that were affected, and we have identified the code change that will prevent this from happening during future maintenance.
The latest update from Honeybadger.
State
Resolved
Started
Lasted
1 min
Worst impact
Notice
Timeline
1 updateResolved
1 min 100%
Updates
Times in UTCAs posted by Honeybadger
Between 13:38 and 13:45 UTC on November 7, during planned maintenance on one of our Redis servers, part of our error-processing pipeline failed after the server switched to its upgraded node. Processing of incoming errors in the US region was delayed by up to about six minutes. No error data was lost: every error report we received was stored. For roughly 1,900 error reports received between 13:38 and 13:41 UTC, some follow-up steps did not run. As a result, you may not have received an alert for a new error first seen in that window, and a resolved error that recurred in that window may not have been automatically reopened. Some of these occurrences may also appear more than once in search results and occurrence counts. The issue has been resolved and processing has been normal since 13:45 UTC. We are working on fixing the alerts and duplicate occurrences that were affected, and we have identified the code change that will prevent this from happening during future maintenance.
Honeybadger in the last 90 days
Full historyIncidents in 90 days
3
Days with an incident
4
Median duration
1 min
This incident
About the median
Other Honeybadger incidents
All incidentsHoneybadger·Partially Degraded Service
Honeybadger reported that outbound SMS via Twilio did not work correctly. Honeybadger marked the incident as resolved. The incident lasted about 2397 minutes.
Honeybadger·Elevated failure rates on the US error reporting API
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 capaci
Follow Honeybadger
Your coding agent knows when Honeybadger is down, and tells you when a failure is theirs, not yours. You can also get Honeybadger incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.live/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "honeybadger" and tell me if Honeybadger has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.live/feed.xml?providers=honeybadger/feed subscribe https://outages.live/feed.xml?providers=honeybadgerFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane