Is Claude Down? How to Check and What to Do Meanwhile

To see whether Claude is down, open status.claude.com, Anthropic’s official status page; the old status.anthropic.com address now redirects there. It shows each part of the service separately, including claude.ai, the Claude API and Claude Code, and lists any active incident. If everything shows Operational and Claude still fails, the problem is usually not an outage: it is a usage limit, a temporary capacity limit, a sign-in problem or your network, and the error message says which. Below is how to read the page, how to tell those apart, and what to do while you wait.

Check the official status page first

Anthropic’s status page↗ (opens in a new tab) is the authoritative source: it is where Anthropic posts incidents and updates them until they are resolved. Third-party “is it down” sites collect reports from other users, which can be a useful second opinion, but they show what people are experiencing rather than what Anthropic has confirmed. As of September 30, 2026 the page lists six components:

• claude.ai: the Claude app at claude.ai.
• Claude Console (platform.claude.com): the developer console, where API keys and billing live.
• Claude API (api.anthropic.com): what developers and many third-party tools call.
• Claude Code: the coding agent, in the terminal, editors, desktop and web.
• Claude Cowork: longer jobs run from the desktop app.
• Claude for Government.

Each component shows one of five states: Operational, Degraded Performance, Partial Outage, Major Outage or Under Maintenance. Below the components are a historical uptime view and past incidents, each with its own timeline of updates. Because the components are listed separately, one can be down while another works: a claude.ai incident does not mean Claude Code is out, and the reverse.

Get told instead of checking

The Subscribe to Updates button on the page offers email, text message, webhook, Slack and Microsoft Teams notifications, and there are RSS and Atom feeds of the incident history. A Slack or Teams subscription in a shared channel saves everyone from checking separately. If you reach Claude through Amazon Bedrock, Google Cloud or Microsoft Foundry, that provider’s own status page is the one to watch; Claude Code’s error messages name the right page for your setup.

Errors that are not outages

Most “Claude is down” moments are one of these. Read the exact message; it is usually specific.

• Usage limits. On claude.ai: “Approaching 5-hour limit”, then “5-hour limit reached - resets [time]”. In Claude Code: You've hit your session limit · resets 3:45pm, or a weekly, Opus or Sonnet limit. Your plan’s allowance ran out; it comes back at the time shown. On Pro and Max the allowance is shared between the Claude apps and Claude Code.
• Capacity constraints on claude.ai: “Due to unexpected capacity constraints, Claude is unable to respond to your message. Please try again soon.” Anthropic’s Help Center↗ (opens in a new tab) says these are not outages but load management at peak demand, and that they do not appear on the status page.
• Overloaded in Claude Code: API Error: Repeated 529 Overloaded errors. The API is at capacity across all users. It is not your usage limit and does not count against it.
• Server is temporarily limiting requests (not your usage limit): a short server-side throttle. Wait briefly and retry.
• Request rejected (429): the rate limit on your own API key or cloud project, not Anthropic’s service. Run /status in Claude Code to check a stray ANTHROPIC_API_KEY is not routing you through a low-tier key.
• Sign-in problems: Not logged in, an expired login, 401 or 403 errors. Run /logout, then claude to sign in again; on claude.ai, try without a VPN or browser extensions and clear the site’s cookies.
• Network: Unable to connect to API usually means your connection, proxy or firewall. Try another network before assuming an outage.

Two Anthropic pages disagree slightly here. The Help Center says capacity issues do not appear on the status page, while Claude Code’s error reference↗ (opens in a new tab) tells you to check the status page for capacity notices when you see a 529. In practice: check the page, and if it is green, treat an overload message as temporary and retry in a few minutes. A 500 error is different: it is a real failure inside the API, and if it persists with no posted incident, /feedback in Claude Code reports it.

Is it you or them? A two-minute check

1. Open status.claude.com and find the component you use.
2. Read the whole error message. A reset time means a usage limit; “capacity” or “overloaded” means demand; “not logged in” means sign-in.
3. Try a second surface. If the desktop app fails, try claude.ai in a browser; if Claude Code fails, try a chat.
4. Try a second network, such as your phone’s hotspot, to rule out a proxy or VPN.
5. In Claude Code, run /status to confirm which account and credential are active, and /usage to see your limits and when they reset.

What to do meanwhile

Keep working on something else

• Switch model. Claude Code tracks capacity per model, and the Opus and Sonnet limits each apply to one model family, so /model can keep you going when one model is overloaded or capped. The session and weekly limits cover every model, so switching does not help there.
• Switch surface. If one component is degraded and another is not, use the one that works: the browser instead of the app, or a chat for the thinking while Claude Code is out.
• Let Claude Code retry. It already retries temporary failures up to ten times with increasing waits before showing an error. For unattended CI jobs, CLAUDE_CODE_RETRY_WATCHDOG=1 makes it keep retrying capacity errors instead of failing the run.
• Wait out a usage limit in place. In an interactive session on a claude.ai subscription, Claude Code can wait and continue the interrupted task after the reset, showing Usage limit reached · continuing automatically at 3:45pm · esc to cancel.

Or stop cleanly

An outage in the middle of a long task is mostly a problem of lost context. Your original message stays in the conversation, so after a transient error you can type “try again” rather than pasting a long prompt. If you are stopping for longer, three habits make restarting easy:

• Name the session with /rename, then come back with claude --resume <name>, or claude --continue for the latest one in that folder. Anthropic’s session docs↗ (opens in a new tab) explain what a resumed session restores.
• Commit or stash what is on disk. Checkpoints cover Claude’s edits, but git is the undo that survives anything.
• Write down where you stopped: what was done, what was half done, what the next step was. That note is what lets a fresh session, or a different assistant, pick up without re-reading everything.

Keep the state on a board, not in the session

The third habit is the one that pays off beyond outages. If the plan and progress live only in a conversation, an outage, a usage limit or a crashed terminal costs you the thread. On fenbs, the task holds it: the note says what the problem is, the plan says how it will be done and gets rewritten as things change, a comment records where the work stopped, and the test status says what was checked. When the service is back, a new session calls fenbs_get_context, reads the rules on the Decisions and rules page and the tasks In Progress, and carries on. History shows who moved what, so you can see what the assistant finished before it stopped. fenbs is an online service too, so for a copy you can keep offline, Copy as Markdown puts the board on your clipboard. Handing work between AI agents and people covers the handoff note in detail.