Is Honeycomb Down?

No — Honeycomb is up

Reachable from all 8 checked regions

Average response time: 476ms

Last checked 2 hours ago · checks run every 6 hours

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

Honeycomb uptime

100%

Last 7 days

—

Last 30 days

—

Last 90 days

—

Avg response, 30 days

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

30-day history

6-day clean streak

Jul 25 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.

jnb

1138ms

DNS 0ms TCP 0ms TLS 5ms TTFB 658ms

lax

234ms

DNS 0ms TCP 2ms TLS 4ms TTFB 187ms

lhr

357ms

DNS 0ms TCP 2ms TLS 6ms TTFB 151ms

nrt

722ms

DNS 0ms TCP 2ms TLS 6ms TTFB 250ms

ord

158ms

DNS 0ms TCP 2ms TLS 4ms TTFB 143ms

sin

957ms

DNS 0ms TCP 1ms TLS 3ms TTFB 314ms

sjc

380ms

DNS 0ms TCP 19ms TLS 23ms TTFB 274ms

syd

817ms

DNS 0ms TCP 1ms TLS 4ms TTFB 260ms

yyz

183ms

DNS 0ms TCP 8ms TLS 12ms TTFB 149ms

What Honeycomb does

Honeycomb is an observability platform built around wide events and distributed traces, used by engineering teams to ask open-ended questions about production rather than watch fixed dashboards. Services send telemetry through OpenTelemetry, and teams rely on it for SLOs, triggers and incident debugging. It runs separate US and EU environments, and an outage removes visibility exactly when it is most wanted.

What an outage looks like

Event ingest at api.honeycomb.io rejects or drops data, so recent time ranges look empty and a healthy service appears to have stopped serving traffic. Queries in the UI time out or return partial results. Triggers and SLO alerting do not fire, which is silent by nature. The EU1 and US1 environments fail independently, so only one may be affected.

What to do about it

status.honeycomb.io reports ingest, querying, the app interface and Trigger and SLO alerting separately for US1 and EU1, so start by confirming which environment and which function is affected. Treat a sudden drop to zero traffic as a Honeycomb ingest problem until proven otherwise, and fall back to another signal, logs or a load balancer's own metrics, before declaring an incident of your own.

Is it down for everyone, or just you?

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

Test it yourself

Related services

Honeycomb outage FAQ

My traffic dropped to zero in Honeycomb. Is my service down?

Check ingest first. A sudden flat line across every service at once is far more often an ingest problem at Honeycomb than a simultaneous failure of everything you run. Confirm with a signal that does not pass through Honeycomb, such as a load balancer's own metrics or application logs, before waking anyone or declaring an incident.

Do triggers and SLO alerts still fire during a Honeycomb outage?

Not reliably, and that failure is silent. Trigger and SLO alerting is a separate component from ingest and querying, so alerts can stop while the UI works. Because a missing alert looks exactly like nothing being wrong, treat an alerting incident as a reason to watch systems manually rather than assuming quiet means healthy.

Is telemetry lost while ingest is unavailable?

Expect a gap. Whether telemetry rejected during an ingest incident survives depends on your own collector rather than on Honeycomb: an OpenTelemetry Collector with a persistent queue can hold and resend it, while a direct exporter with a short retry generally cannot. Decide on that buffering before an outage, because the setting cannot be applied retroactively.

Does an EU1 incident affect US1?

They are reported and operated separately. The status page lists ingest, querying, the app interface and alerting individually for US1 and EU1, so an EU environment problem leaves US teams unaffected. Check which environment your organisation sends data to, since the two use different hostnames and a team can easily end up watching the wrong one.

How we measure this

We request Honeycomb's public endpoint every 6 hours from Fly.io regions across six continents — 8 of them answered the most recent check.
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 Honeycomb 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 Honeycomb goes down

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

Start Free Monitoring

Free plan available No credit card required