All Systems Operational

About This Site

Welcome to the Honeybadger.io status page.

Web Application Operational
90 days ago
100.0 % uptime
Today
API Operational
90 days ago
100.0 % uptime
Today
Outbound SMS via Twilio Operational
Payments via Stripe Operational
AWS cloudFront Operational
AWS route53 Operational
Pusher Pusher REST API Operational
Pusher WebSocket client API Operational
Pusher Presence channels Operational
Pusher Webhooks Operational
Slack Notifications Operational
Slack Apps/Integrations/APIs Operational
PagerDuty Events API (US) Operational
PagerDuty Events API (EU) Operational
Outbound email Operational
AWS dynamodb-eu-central-1 Operational
AWS dynamodb-us-east-1 Operational
AWS dynamodb-ap-southeast-1 Operational
AWS dynamodb-eu-west-2 Operational
AWS dynamodb-us-west-2 Operational
AWS ecs-us-east-1 Operational
AWS ecs-eu-central-1 Operational
AWS elb-eu-central-1 Operational
AWS elb-us-east-1 Operational
AWS lambda-eu-central-1 Operational
AWS lambda-ap-southeast-1 Operational
AWS lambda-eu-west-2 Operational
AWS lambda-us-east-1 Operational
AWS lambda-us-west-2 Operational
AWS s3-eu-central-1 Operational
AWS s3-sa-east-1 Operational
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance
Major outage
Partial outage
No downtime recorded on this day.
No data exists for this day.
had a major outage.
had a partial outage.

Aug 16, 2026

No incidents reported today.

Aug 15, 2026

Resolved - 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.

Aug 15, 13:48 PDT

Aug 14, 2026

No incidents reported.

Aug 13, 2026

No incidents reported.

Aug 12, 2026

No incidents reported.

Aug 11, 2026

No incidents reported.

Aug 10, 2026

No incidents reported.

Aug 9, 2026

No incidents reported.

Aug 8, 2026

No incidents reported.

Aug 7, 2026

No incidents reported.

Aug 6, 2026

No incidents reported.

Aug 5, 2026

No incidents reported.

Aug 4, 2026

No incidents reported.

Aug 3, 2026

No incidents reported.

Aug 2, 2026

No incidents reported.