Methodology

Where every number on this page comes from, and what it means.

Last updated: April 2026 · This page changes whenever the math changes.

Status pages are easy to make and hard to make honestly. The dashboard you are reading would still load if every calculation on it was wrong. So here is the full description of what we measure, how we measure it, what we deliberately leave out, and the trade-offs we picked. If you find a discrepancy between this page and the code, the code is the source of truth — but please tell us so we can update the description.

1. Status snapshot

The big banner at the top of the homepage — "All Systems Operational" versus "System Disruption Detected" — is driven by a single field on Anthropic's public Statuspage feed: summary.status.indicator.

Statuspage emits one of four indicator levels:

We treat only none as "All Systems Operational." Anything else flips the banner red. We do this because users overwhelmingly tell us they want a binary signal at the top of the page — when the banner is green, they assume nothing is going on, full stop. Showing yellow for "minor" turned out to confuse more people than it helped.

The trade-off: a single degraded component (say, Claude for Government during a regional cloud incident) will turn the banner red even if your specific surface — claude.ai or the API — is fine. The component grid below the banner shows exactly which surface is affected, and that is where you should look during a yellow-zone event.

2. Component status mapping

Statuspage tracks five Claude components, each with one of four status values. We map them down to three buckets for the UI:

Statuspage value Our bucket UI color
operationaloperationalgreen
degraded_performancedegradedamber
partial_outageoutagered
major_outageoutagered

Both partial_outage and major_outage roll up into the same red "outage" bucket because in practice users can not act on the distinction during the incident — both mean "do not rely on this surface right now."

3. 30-day uptime calculation

Every component has a 30-bar strip showing the last 30 days of uptime. The percentage shown next to each component ("99.86% uptime over 30 days") is the average of those 30 day-level uptime values, not a single weighted-by-seconds number across the month. This matches how most engineering teams talk about uptime informally.

For each of the last 30 days, the day-level uptime number is calculated as: 

uptime_for_day = 1 − (downtime_seconds / day_seconds)

with the following rules:

  1. We pull every incident from the Statuspage feed where the affected components include this one. For each incident, we compute the overlap between the incident's created_at / resolved_at window and the day's UTC midnight-to-midnight window. Unresolved incidents extend to now.
  2. Incidents with impact critical or major count as outage seconds. Incidents with impact minor count as degraded seconds. Both reduce uptime, but only outage minutes change the day's color.
  3. Overlapping incidents are merged before being summed, so two simultaneous incidents on the same component do not double-count downtime. (This matters during cascading incidents where Anthropic posts a parent incident plus a child incident covering the same window.)
  4. For today, the denominator is "elapsed seconds since midnight UTC," not 86,400. This avoids the common bug where a status page shows 99.999% at 00:01 UTC just because almost no time has passed yet.

The 30-day percentage shown in the page hero (the "Avg 30-day uptime" curve) is the simple arithmetic mean of the daily uptime values across all monitored components. It is intentionally conservative — when one component degrades for a few hours, every component-day in the average drops a little.

Why our number can be lower than Anthropic's

Cloud-vendor uptime numbers in marketing materials typically count only full outages against the percentage, and exclude partial outages, single-region disruptions, or incidents the provider classifies as not affecting the SLA. We count every major+ critical incident, regardless of whether Anthropic later attached SLA credits to it. If our 30-day number is 99.7% and Anthropic's published number is 99.95%, both can be correct under their own definitions. We chose the stricter one because users tell us "show me what actually happened, not the marketing number."

4. Global latency probes

The latency table on the homepage shows TTFB (time-to-first-byte) for unauthenticated HTTPS requests to https://claude.ai from 17 countries. We pick the marketing host instead of api.anthropic.com for two reasons: (1) it consumes no API quota and triggers no model invocations, and (2) it routes through the same edge that the chat web app uses, which is the surface most users actually care about when they type "is Claude slow."

Why 17 countries

We use check-host.net's public probe network. The 17 countries currently sampled are: US, BR, GB, DE, FR, NL, FI, IT, TR, AE, IN, SG, JP, HK, CN, VN, ID. The set is biased toward (a) regions where Claude is widely used, (b) regions that are not behind Cloudfront edges that already cache locally, and (c) regions where access policy is non-trivial (UAE, Turkey, China — countries where Claude's accessibility varies materially over time).

Multi-node redundancy

Each country is sampled from up to 3 redundant probe nodes. This is the difference between a latency dashboard you can trust and one that flickers because a single probe machine is having a bad day. After each measurement cycle, for every country we:

  1. Collect every node's result for that country.
  2. Filter to nodes that returned a valid HTTP status (anything other than connect-error or timeout).
  3. Pick the lowest valid latency as that country's number for this cycle.
  4. If every node failed, the country shows as timeout (-1ms).

We pick best-of rather than median because for an end-user the answer to "can I reach Claude from this country right now" is governed by the best-routed path, not by the average path quality. A user with bad luck on one ISP route might see worse, but if any path works, claude.ai is usable.

Probe cadence

A full multi-country sweep runs every 5 minutes via Vercel Cron. Users can trigger an out-of-band refresh by clicking the refresh control on the latency widget; that path is rate-limited to 10 manual checks per IP per 60 seconds. If a manual refresh hits the cap or finds the cached data is already newer than what was displayed, no upstream probe runs — we just return the cache.

What latency does not tell you

Low TTFB does not mean Claude can answer your prompt — it means the marketing edge is reachable. During large model-tier outages, claude.ai often loads quickly and fails inside the chat WebSocket. The latency widget will be green during these incidents and the component grid (which reflects Anthropic's own status) will be red. Always read both.

5. Community reports

Anyone can submit a report through the "Report an Issue" button on the homepage. Reports have a category (outage or latency) and a free-text description capped at 80 characters. Submissions are anonymous; we do not collect names, emails, or accounts.

Community reports are a noise-prone signal — they spike during real incidents but also spike when a popular creator tweets "Claude is broken." We display the raw counts unfiltered and trust readers to compare against the component grid and latency widget on the same page. We do not suppress, edit, or curate individual reports.

6. Caching & freshness

Statuspage's public API has a CDN cache of about 10 seconds and is documented as having no rate limit, but we still cache aggressively because the page is server-rendered on every request and we are kind to upstreams.

Data Cache TTL Refresh trigger
Statuspage summary + incidents120son-miss page render
Latency table1800s5-min cron + user refresh
RSS feed300son-miss feed request
Community reportsno TTLlive (3-day rolling)
IP rate-limit counters60sper request

Cache layer is Cloudflare KV via the REST API. Reads are sub-50ms from Vercel; writes are non-blocking and tolerate failure (a failed KV write means the next request just refetches upstream — no user-visible error). The "Refreshed: HH:MM:SS UTC" label on the page is the summary.page.updated_at from Statuspage, not our cache write time, so it reflects how fresh Anthropic's data is, not ours.

7. Incident history

The "Historical Events" feed at the bottom of the homepage shows the 20 most recent incidents from Statuspage, across all five monitored components. For each incident we show:

We do not paraphrase, summarize, or edit the incident text — what you see is the original Statuspage update verbatim. The shortlink on each card points back to the canonical incident page on status.claude.com so you can verify.

8. Known limitations

Things this page does not tell you, and why:

9. Reproducibility

Every input we use is public. If you want to replicate any number on this page from scratch:

These endpoints are unauthenticated, CORS-permissive, and explicitly intended for third-party reuse by Atlassian's Statuspage product. You can build your own dashboard from them; if you do, we would love to see it.

10. Change log for this page

When the methodology changes — different country list, different cache TTL, different uptime formula — we update this page and add a new entry above. We do not silently change calculations.