Claude failing in one place does not establish that every Claude product is down. A conversation in the browser, an API request from your application and a Claude Code session are different things to test. Start by naming which one stopped working.
Check the official Claude status page from Anthropic, the company behind Claude. Read the component and incident description rather than only the headline. This page explains how to diagnose a failure; it does not report Claude's live status or promise a recovery time.
Is it happening to other people?
Ask a teammate to try a small, non-sensitive request in the same product. Compare the model if you can, because success with another model is not the same test. Record whether the failure happens before login, before generation or partway through a response.
Try another permitted network or client only after saving your work. If all affected users share an organization or office network, the problem could still be specific to that account or connection. Avoid turning one successful test from a different environment into proof that nothing is wrong.
Keep the exact error text and the time with its timezone. A screenshot can help preserve a browser error, but remove private conversations and account details before sharing it outside your team. You do not need to reveal the prompt to establish that generation failed.
Which part of Claude is failing?
Use the following distinctions when reading the status page and collecting evidence.
| Symptom | Useful boundary to check |
|---|---|
| Claude web will not load or sign in | Browser session, login and the web product. |
| A chat opens but cannot answer | Model, conversation and generation behavior. |
| Your application receives API errors | Endpoint, response body and organization limits. |
| Claude Code stops making progress | Local tools, authentication, model request and permissions. |
| Claude fails inside another editor | That editor's service path as well as Claude availability. |
An old conversation still visible in a tab is not evidence that new requests work. Likewise, a working website does not prove that an application's API credentials are valid. Test the operation you need to resume.
Is a usage limit an outage?
A limit message describes something different from an unavailable service. Read the full error before deciding to wait for an incident update. An account can be unable to make more requests while other accounts work normally.
Anthropic's API error documentation distinguishes authentication and permission errors, rate limiting and overload. In particular, a 429 response indicates rate limiting, while a 529 response indicates temporary overload. Preserve the error type and request identifier rather than reporting only “the API failed.”
Do not rotate keys or change billing based on an unfamiliar error number alone. Check the account and project you intended to use, then consult the documented error meaning. A permanent configuration problem and a temporary server failure call for different next steps.
Why did the response stop halfway through?
A connection can fail after an answer starts. Partial text does not tell you whether the provider completed the response, whether your client lost the connection, or whether an application stopped consuming it. Keep the incomplete result labeled as incomplete.
For API integrations, inspect stream completion and error handling as well as the initial response status. For a browser conversation, save useful text before refreshing and try one short request only if doing so will not repeat an action with external effects.
If an agent was using tools, inspect what those tools already did. A stopped answer is not proof that a file write, command or remote action was cancelled. Do not use another full agent run as a connectivity test.
Is Claude Code broken locally or remotely?
Identify the last visible step. A shell command waiting for input, an unavailable package registry or a permission prompt can make the session appear stuck even when model requests are healthy. Check the terminal and repository state before restarting the session.
If ordinary local commands work but model requests consistently fail, compare that symptom with the official incident. If Claude works directly but fails through another product, investigate that product too. The Cursor diagnostic guide covers this distinction for editor and cloud-agent failures.
Keep the investigation narrow. Changing extensions, network settings and credentials together can turn a single unknown into several. Save a concise record of each check and result so a teammate can continue without repeating everything.
What do outside reports and partial outages mean?
Downdetector and social posts can show that people noticed similar problems around the same time. They are supporting evidence, not confirmation of a cause. Compare products and symptoms: complaints about a web login do not establish an API outage.
A partial outage can affect a model, product or subset of customers while other requests succeed. It can still fully block your work. Read the incident notes for its actual scope. If status looks normal despite repeated failures, see why status pages can say operational when things are broken.
What should I do once an outage looks likely?
Stop repeating long prompts and preserve any unfinished work. Tell the team which product is affected and whether the provider has confirmed it. Choose a task you can complete from local files, documentation or tests while one person follows updates.
Use the Claude outage playbook for practical next steps and recovery checks. Confirm one small request and inspect previous agent actions before resuming normal work. Recovery means your required operation works again, not merely that a different Claude surface happens to load.