Of the five Claude components on the public Statuspage, Claude Code is the youngest. It was added on 2025-05-22 — almost two years after the original three components (claude.ai, platform.claude.com, the API). It joined a category that did not previously exist on the page: a developer CLI as a first-class status surface.
A year of public incident data on Claude Code is enough to see where its stability profile diverges from the rest of the Claude family. This post is a reading of that data — what is the same, what is different, and what the differences imply about CLI tool reliability.
What Claude Code is (briefly)
For readers who do not use it: Claude Code is Anthropic’s official command-line interface for Claude. It is a terminal-resident agent that can read your filesystem, run shell commands, edit files, and invoke Claude under the hood for reasoning. It runs locally as a node binary; the local process talks to Anthropic’s API for every Claude-side operation. It launched in early 2025 and has shipped continuously since.
The component on Statuspage covers the user-facing CLI as a whole — local binary plus the cloud-side surfaces it depends on (auth, command sync, the IDE-extension bridge). It does not cover individual model availability inside the CLI; if Opus is overloaded but the rest of the Claude API is fine, that shows up on the API component, not on Claude Code.
The first reading: Claude Code’s stability tracks the API
Roughly three-quarters of incidents that affect Claude Code also affect the API component. This is unsurprising — the CLI’s “do something useful” path is mostly Claude API calls, and a degraded API surface degrades the CLI by definition. When the API is major, Claude Code typically goes minor or major simultaneously.
The corollary is that Claude Code-specific incidents — the ones that hit the CLI surface but leave the API green — are interesting. They are the incidents that tell you something CLI-specific is going on. The shape of those incidents over the last year breaks roughly into three categories:
- Auth and login flow issues. The CLI’s first-time setup involves an OAuth-style browser handshake. When that flow breaks, the API is fine but new users cannot log in.
- Hosted MCP / tool-bridge issues. Some Claude Code features rely on Anthropic-hosted intermediate services for things like remote tool registration. When those wobble, the local binary works but specific feature paths fail.
- Rate-limit edge cases. The CLI’s request shape — long context, many tool turns — produces different rate-limit behavior than typical API consumers, and a small fraction of incidents are CLI-specific quota-handling issues.
Each of these is a category that simply does not exist for a chat web app or a generic API user. The CLI’s incident profile is genuinely its own thing.
The second reading: incidents per quarter has trended down
Reading the year of data quarter-by-quarter, the count of minor+ Claude Code incidents has trended down meaningfully over the four quarters since the component was added. The first quarter after launch had the most. Each subsequent quarter has had fewer — not zero, but a clear downward slope.
This is the canonical CLI tool stability curve: noisy at launch, stabilizing over time. We see the same pattern in other developer tools we follow informally — the first few months of a new CLI surface a long tail of edge cases that did not show up in pre-launch testing, and a steady release cadence chips away at them.
What this implies for someone deciding whether to depend on Claude Code in production tooling: the surface today is meaningfully more stable than the surface six months ago. The early-launch reliability profile is not a fair test of the current surface.
The third reading: incident duration is short
Across the full year, the median Claude Code incident duration (from created_at to resolved_at) is roughly 30–60 minutes. The 90th percentile is in the 2–3 hour range. There are a small number of multi-hour outliers, almost always tied to broader API-side incidents the CLI inherited.
Short median duration is partly a function of the CLI’s failure modes. Auth bugs, MCP bridge issues, rate-limit edges — these are typically isolatable and rollback-able. They do not require model-side fixes that cascade through deployment. The contrast is the API component, where some categories of incident (regional capacity, model rollout) take longer to fully resolve.
Practically: if Claude Code is in major and you depend on it in a build pipeline or daily workflow, the expected wait is closer to “go grab coffee” than “rearrange your day.”
The fourth reading: the CLI does not get its own banner
A subtle but real fact: when the official Statuspage summary.status.indicator is set to major for the page as a whole, that classification weights events at claude.ai and the API more heavily than Claude Code. A Claude Code-only major incident often results in a page-level indicator of minor, because the upstream component is “broadly degraded” rather than “broken for everyone.”
This is a reasonable choice on Anthropic’s part — a CLI used by a smaller fraction of users should not flip the entire page red. But it does mean the dashboard banner on this site (which mirrors the page-level indicator) can be amber while Claude Code specifically is red. Read the component grid, not the banner, when CLI behavior is what you care about.
Comparing to the chat web app
A useful contrast: claude.ai (the web chat) has a different incident profile from Claude Code. claude.ai’s incidents tend to be:
- Front-end-deployment-related — a bad rollout takes the chat surface down for some users while the API and CLI are fine.
- Auth-and-session-related — sign-in flow regressions, particularly during platform migrations.
- CDN-and-edge-related — traffic surges or edge node issues that show up on the marketing front-end before they reach the API.
Claude Code shares almost none of these. The CLI does not deploy a front-end, does not have an auth-and-session model that depends on browser cookies, and is largely insulated from CDN edge issues except at the very first OAuth step. It inherits a different set of failure modes — those of a CLI distribution channel and the binary’s local error handling — that simply do not exist for a web app.
This is not a Claude-specific observation. It is the general pattern: CLI tools and web apps fail in different shapes, and the same product family will have different incident profiles for the two surfaces.
What this implies for tooling that depends on Claude Code
A few practical implications.
Treat Claude Code stability as a separate signal from API stability, even though they are correlated. If you have automation that runs Claude Code in a CI pipeline, watching the Claude Code component is not redundant with watching the API component — there are CLI-specific failure modes that the API component will not surface.
Subscribe to the RSS feed. The Claude Code component is on the same Statuspage as the others, so our RSS feed covers it. Filtering for items where the affected components include Claude Code is a one-line filter in any automation platform.
Plan for short outages, not long ones. The empirical median is short. Your retry-and-fallback policy in a build pipeline can be calibrated against “wait an hour, re-run” rather than “fail for the day.” This is a real operational difference from, say, planning around AWS regional outages.
Read the incident text, not just the component status. Claude Code’s major events have, in practice, often been narrower than the badge implies — a specific feature broken, a specific platform’s binary stalled, a specific install path failing. The component status reflects the worst case across users; the incident text reflects the actual scope.
Where Claude Code’s profile is going
We do not have access to Anthropic’s internal roadmap, but the trajectory of the public data suggests two near-term predictions:
- The downward slope of incident count is likely to continue but flatten. Mature CLIs trend toward a stable floor — typically 1–3 minor incidents per quarter, all related to platform churn (new OS versions, dependency upgrades, runtime ecosystem shifts). We are probably not far from that floor.
- The shape of incidents will continue to shift toward integration and feature-bridge issues, away from binary distribution and core CLI behavior. As the CLI surface adds more deeply integrated features (MCP servers, IDE bridges, cloud-side memory), the failure modes will increasingly be at the integration boundaries, not in the CLI itself.
Both predictions are based on a year of public data and may be wrong. The data is on the official Statuspage, filtered to the Claude Code component. Read it for yourself; it does not take long.
For now, Claude Code is a well-behaved component with a short-incident profile, a downward-trending bug count, and a set of failure modes distinct from the rest of the Claude family. If you depend on it, watch it as its own signal.