Skip to main content
Honeybadger logo

Is Honeybadger Down?

No — Honeybadger is up

Reachable from all 8 checked regions

Average response time: 530ms

Last checked · checks run every 6 hours

Official status page: https://status.honeybadger.io

Honeybadger uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
449ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 13 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

13-day clean streak
Aug 22: no data
Aug 23: no data
Aug 24: no data
Aug 25: no data
Aug 26: no data
Aug 27: no data
Aug 28: no data
Aug 29: no data
Aug 30: no data
Aug 31: no data
Sep 1: no data
Sep 2: no data
Sep 3: no data
Sep 4: no data
Sep 5: no data
Sep 6: no data
Sep 7: no data
Sep 8: 100.00% uptime, 38 checks
Sep 9: 100.00% uptime, 32 checks
Sep 10: 100.00% uptime, 32 checks
Sep 11: 100.00% uptime, 32 checks
Sep 12: 100.00% uptime, 31 checks
Sep 13: 100.00% uptime, 32 checks
Sep 14: 100.00% uptime, 31 checks
Sep 15: 100.00% uptime, 31 checks
Sep 16: 100.00% uptime, 32 checks
Sep 17: 100.00% uptime, 32 checks
Sep 18: 100.00% uptime, 32 checks
Sep 19: 100.00% uptime, 32 checks
Sep 20: 100.00% uptime, 16 checks
Aug 22 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

dfw
414ms
DNS 152ms TCP 32ms TLS 38ms TTFB 288ms
ewr
164ms
DNS 102ms TCP 8ms TLS 13ms TTFB 136ms
fra
187ms
DNS 48ms TCP 3ms TLS 115ms TTFB 174ms
gru
181ms
DNS 144ms TCP 3ms TLS 10ms TTFB 164ms
iad
105ms
DNS 81ms TCP 2ms TLS 6ms TTFB 95ms
jnb
2734ms
DNS 366ms TCP 37ms TLS 345ms TTFB 1387ms
lax
183ms
DNS 98ms TCP 10ms TLS 17ms TTFB 142ms
lhr
275ms
DNS 61ms TCP 15ms TLS 127ms TTFB 221ms

What Honeybadger does

Honeybadger is an application monitoring service covering exception tracking, uptime checks and cron job monitoring, used mainly by Ruby, JavaScript, PHP, Python and Go teams. Applications report errors to its API and Honeybadger groups them, tracks their history and notifies the team. Because it is the thing that tells you something else broke, its own failures are unusually easy to miss.

What an outage looks like

Errors stop appearing in the dashboard and the application looks unusually healthy, which is the most dangerous symptom this service has. Notifications stop arriving in Slack, PagerDuty, email or SMS while errors continue to be recorded. Uptime and cron checks may not report, so a missed job produces no alert. The web application can be unreachable while error ingestion continues normally.

What to do about it

Read status.honeybadger.io, which is unusually detailed: alongside Web Application and API it reports its own upstream dependencies as components, including Outbound email, Outbound SMS via Twilio, Slack Notifications, PagerDuty Events API for US and EU, Pusher, Stripe and a long list of per-region AWS services. Match the symptom to the row. If only the notification components are affected, errors are still being collected and you should watch the dashboard directly until they recover.

Is it down for everyone, or just you?

If this page says Honeybadger is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 18 cities across three regions to find out where it breaks.

Test it yourself

Related services

Sentry
Sentry
Rollbar
Rollbar
Bugsnag
Bugsnag
PagerDuty
PagerDuty

Honeybadger outage FAQ

I have stopped getting Honeybadger alerts. Does that mean nothing is wrong?
Not necessarily, and this is the failure worth planning for. Honeybadger reports Outbound email, Outbound SMS via Twilio, Slack Notifications and the PagerDuty Events API as components separate from error ingestion, so errors can keep being recorded while no notification reaches you. Silence from an error monitor is ambiguous. Open the dashboard directly during an incident rather than treating a quiet channel as good news.
Will errors sent during a Honeybadger outage be lost?
Honeybadger client libraries generally send asynchronously and do not block your application, but they are not an unlimited buffer, and Honeybadger does not publish a guarantee covering every failure mode. Treat the incident window as a possible gap in your error history rather than assuming full capture, and check your own application logs for that period if you need certainty about what happened.
Is my Honeybadger problem actually an AWS or Twilio outage?
Quite possibly, and the status page is built to answer that. Honeybadger publishes AWS DynamoDB, ECS, ELB, Lambda, CloudFront and Route 53 per region as components, plus Twilio, Stripe, Pusher, Slack and PagerDuty. An incident on one of those upstream rows explains a Honeybadger symptom without Honeybadger itself having changed, and it usually means other tools you use are affected too.
The Honeybadger dashboard is down. Is error collection still working?
Often yes. Web Application and API are separate components, so the interface can be unreachable while the API keeps accepting error reports from your applications. Nothing needs re-sending in that case. Wait for the Web Application row to recover and the errors recorded during the window will be there when you can view them again.
Is Honeybadger down or is my integration misconfigured?
Compare scope. A configuration fault affects one application or one environment, usually after a deploy or an API key change, while a Honeybadger incident affects every project at once. status.honeybadger.io names the affected component directly. If the page is all-clear and only one of your applications has gone quiet, check that project's API key and reporting environment first.

How we measure this

  • We request Honeybadger's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Honeybadger publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Honeybadger goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from up to 18 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required