Claude AI Status — How to Read Anthropic’s Status Page

The authoritative source for Claude AI status is Anthropic’s official status page at status.anthropic.com. It tracks six components independently — claude.ai, the Claude Console, the Claude API, Claude Code, Claude Cowork, and Claude for Government — publishes timestamped incident updates, and lets you subscribe by email, SMS, Slack, webhook, or RSS. Most people, though, only glance at the green banner and miss what the page can actually tell them. After following it through dozens of incidents, this is my complete guide to reading it properly: what each component covers, what the severity levels mean, how to get alerted automatically, and why API status and claude.ai status are not the same thing.

TL;DR: status.anthropic.com (which redirects to status.claude.com) is the only official Claude AI status source. Six components are tracked separately, so always check the one you actually use. Incidents progress through Investigating → Identified → Monitoring → Resolved, with severity shown as degraded performance, partial outage, or major outage. You can subscribe via email, SMS, Slack, webhook, or RSS/Atom — webhook is the right choice for engineering teams. Uptime history is shown as 90-day bars per component, typically in the 99.4–99.9% range.

Where to Find the Official Claude AI Status Page

Anthropic’s status page lives at status.anthropic.com; the URL currently redirects to status.claude.com, and both addresses land on the same page. Bookmark either. It’s a hosted status page of the kind most major SaaS companies run: a component list with colored state indicators at the top, active incidents (if any) above that, uptime bars per component, and a reverse-chronological incident history below.

Two things it is not: it isn’t a live latency dashboard (it won’t show you response-time graphs), and it isn’t instantaneous — a human at Anthropic confirms an incident before it’s posted, which typically takes several minutes from the first user reports. That lag is why crowd sources like DownDetector sometimes light up first. If you’re mid-problem right now and need a triage sequence rather than a reference guide, start with our playbook for checking whether Claude AI is down and come back here for the deeper reading.

The Six Components on the Claude Status Page

The most common mistake with the Claude AI status page is reading it as one global light. It isn’t — Anthropic tracks six components, and they fail independently. Here’s what each one actually covers and who should care about it:

Component	What it covers	Who should watch it
claude.ai	The consumer chat app — web, plus the backend that the mobile and desktop apps use	Free, Pro, and Max subscribers
Claude Console (platform.claude.com)	The developer dashboard: API keys, billing, usage, Workbench	Developers and admins
Claude API (api.anthropic.com)	The Messages API and related endpoints powering integrations and products	Anyone running Claude in production
Claude Code	Anthropic’s agentic coding tool — CLI, desktop, web, and IDE extensions	Developers using Claude Code
Claude Cowork	The Cowork agent surface (research preview)	Pro/Max users on Cowork
Claude for Government	The government-cloud deployment	Public-sector customers

A few practical notes from watching these components over time. First, incidents scoped to a single model (say, elevated errors on one Opus version) usually appear as an incident notice tied to the API or claude.ai component rather than as a separate line — read the incident text, not just the colors. Second, Console being down is annoying but rarely urgent: your API keys keep working even when the dashboard that manages them doesn’t. Third, Claude Code incidents sometimes reflect problems in the surrounding tooling (the web surface, integrations) while raw API access stays healthy — knowing the difference between Claude and Claude Code helps you interpret which component matters for your workflow.

Incident Lifecycle and Severity Levels Explained

Every incident on the page moves through the same four-stage lifecycle, each stage timestamped:

1. Investigating — Anthropic has confirmed something is wrong but hasn’t isolated the cause. Expect little detail at this stage.
2. Identified — the cause is known and a fix is being implemented. The gap between Investigating and Identified is a decent proxy for how gnarly the incident is; in well-handled cases it’s minutes.
3. Monitoring — a fix has been deployed and Anthropic is watching error rates to confirm recovery. Service is usually already usable here, though you may still see residual errors.
4. Resolved — the incident is closed. The full update trail stays in the history.

Severity is expressed through the component state, and the wording matters:

• Operational (green) — no confirmed problems. Not a guarantee of perfection; brief or regional blips can exist below the reporting threshold.
• Degraded Performance — the component works but is slower or flakier than normal. Elevated error rates and sluggish streaming typically land here.
• Partial Outage — a meaningful slice of functionality or users is failing: one model erroring, one region struggling, one feature broken. In my experience this is the most common severity for real incidents.
• Major Outage — the component is broadly unavailable. These are the rare, headline-making events.

The practical takeaway: “Partial Outage” on the API component doesn’t necessarily mean your traffic is affected, and “Degraded Performance” on claude.ai doesn’t mean you’ll see problems at all. Severity describes breadth on Anthropic’s side; your experience depends on which model, feature, and region you’re hitting.

How to Subscribe to Claude AI Status Updates

You shouldn’t have to poll a status page. Anthropic’s page offers five subscription channels via the “Subscribe to updates” button — I verified the current list directly on the page:

Channel	What you get	Best for
Email	A message when an incident is created, updated, and resolved	Most individual users — set it and forget it
SMS	Text alerts on incident creation and resolution	On-call folks who ignore email
Slack	Incident updates posted into a channel you choose	Teams — pipe it into #eng-alerts or #ai-tools
Webhook	A JSON POST to your endpoint on every incident change	Engineering teams wiring status into PagerDuty, Opsgenie, or dashboards
RSS / Atom feed	A machine-readable feed of incidents	Feed readers, internal aggregators, low-effort automation

My recommendation: individuals should take email; teams running Claude in production should take webhook plus Slack. The webhook gives your incident tooling a structured signal you can alert on, and Slack gives humans ambient awareness without anyone having to check a page. If you run internal dashboards, the RSS feed is the cheapest integration — most monitoring stacks can ingest a feed with zero custom code.

One caveat: subscriptions notify you about confirmed incidents. Your own monitoring — error rates on API calls, failed-send counts in the app — will always fire first. Treat the status subscription as confirmation and context, not as your primary detector.

Reading the Uptime History Bars

Below the component list, the page shows a 90-day uptime bar for each component — one thin vertical bar per day, colored by that day’s worst state, with an overall uptime percentage. At the time of writing, components were showing figures in the 99.4%–99.9% range over their 90-day windows.

Percentages compress a lot, so translate them into time. Over 90 days:

• 99.9% ≈ 2.2 hours of cumulative downtime
• 99.5% ≈ 10.8 hours
• 99.0% ≈ 21.6 hours

Three reading tips. First, hover (or tap) a bar to see the incidents behind it — a single bad day can drag a component’s number down noticeably, so distinguish “one rough Tuesday” from “flaky every week.” Second, uptime measures availability, not quality: Anthropic’s own postmortem of the August–September 2025 issues described degraded response quality that wouldn’t fully register as downtime. Third, compare components: if the API shows materially lower uptime than claude.ai over the same window, that tells you where the fragility has been — useful input when you’re deciding how much retry and fallback logic your integration needs.

Below the uptime bars sits the incident history: a reverse-chronological list of every posted incident with its full update trail. It’s worth scrolling occasionally even when nothing is wrong. Reading a month of entries gives you a realistic feel for the platform’s failure profile — which components appear most often, how quickly incidents move from Investigating to Resolved, and how frequently a “quiet” week actually contains two or three small, fast-resolved blips that you never noticed while working.

Claude API Status vs. claude.ai Status: Why They Differ

The chat app and the API share model infrastructure but sit behind different serving layers, different capacity pools, and different failure modes — which is why the status page tracks them separately, and why one is regularly degraded while the other hums along.

• claude.ai can fail while the API is fine. Front-end deploys, authentication problems, and feature-level bugs (attachments, artifacts, search) only touch the consumer app. Developers sometimes verify this in seconds with a one-line API call while chat users are staring at error banners.
• The API can degrade while claude.ai is fine. API traffic has its own rate-limiting and capacity management. Elevated 529 “overloaded” responses can hit API customers during demand spikes that consumer users never notice.
• Model-level incidents can hit both. When the problem is in model serving itself — as in incidents affecting a specific model version — every surface that routes to that model feels it, and the incident notice will usually name multiple affected products.

For API users there’s one more distinction that the status page can’t make for you: a green API component with errors in your logs usually means the problem is your quota, not their infrastructure. A 429 with a retry-after header is your tier’s rate limit doing its job — see our breakdown of Claude API rate limits for how the tiers work. A rising rate of 529s, by contrast, is Anthropic-side pressure and worth checking against the status page. If you’re newer to the API side generally, our Claude API developer’s guide covers error handling in context.

Checking Claude AI Status from the Command Line

Anthropic’s page runs on standard status-page infrastructure, which means it exposes machine-readable endpoints alongside the human-readable page. The simplest one returns the overall status as JSON:

curl -s https://status.claude.com/api/v2/status.json

I ran this while writing this article and got back a compact payload ending in "indicator":"none","description":"All Systems Operational". The indicator field is the part worth scripting against: it reads none when everything is green and changes to a severity value (minor, major, critical) during incidents. Related endpoints on the same base URL return the full component list (/api/v2/summary.json) and unresolved incidents (/api/v2/incidents/unresolved.json), and /history.rss serves the incident feed for anything that ingests RSS.

This is the cheapest possible integration for a team: a scheduled job that fetches status.json, checks the indicator, and posts to your chat tool when it changes. It’s cruder than the official webhook subscription — you’re polling, so you inherit the polling interval as lag — but it needs no registration and can’t miss a renewal email. For a personal setup, I keep a one-line shell alias that prints the description field; it answers “is it them?” faster than opening a browser tab.

Two cautions. Don’t poll aggressively — once a minute is far more than enough for a status page, and the data behind it only changes when a human posts an update. And don’t build alerting only on this: as covered above, the page reflects confirmed incidents, so your own API error rates remain the earliest signal you’ll get. The JSON endpoint is confirmation you can automate, not a monitoring system.

What People Get Wrong About Claude Status

• Trusting third-party “Claude status” sites as primary sources. Plenty of sites (including this one) write about Claude status; only status.anthropic.com is the official record. Everything else is commentary or aggregation with added lag.
• Reading green as “nothing is wrong anywhere.” Green means no confirmed incident. Short-lived or narrow problems can be real and still never make the page.
• Watching the wrong component. If you live in Claude Code, the claude.ai line tells you little. Match the component to your surface.
• Confusing usage caps with incidents. Hitting your plan’s message limit feels like an outage but is documented, deterministic behavior with a reset time. Our guide to Claude AI limits explains the caps in detail.
• Never opening the incident text. The one-line component state hides the useful part: which models, which features, and which regions are affected are all in the incident updates.

Make Status Checking Automatic

The best version of checking Claude AI status is not checking at all: subscribe once (email for individuals, webhook plus Slack for teams), learn the component map so alerts are instantly interpretable, and keep the uptime history in mind when you design retry logic. To see what past incidents actually looked like — dates, causes, and how Anthropic handled them — read our Claude AI incident history, or browse the whole status section for the full cluster.

FAQ