A degraded Anthropic status does not mean every Claude product is failing. Start with current Claude and Anthropic status, then read the official incident's affected products and latest update. Match them to what you were doing: sending a chat, calling the API or running a Cowork task.
An operational indicator is not a test of your account, network or task. If there is no matching notice, preserve the error and continue checking the affected function.
Identify the failing product first
| Where the failure happens | Record before retrying |
|---|---|
| Claude chat in a browser or app | Exact message, time, model and whether a simple new chat works |
| A direct Claude API request | HTTP status, error type, model and request ID |
| A Cowork task | Failed step, connected tool or file, app version and operating system |
| Claude through another platform | Platform, region, model and that platform's error details |
A notice limited to one product or operating system is evidence about that scope. For example, a Cowork file-access failure would not by itself establish an outage of the Claude API. The official Claude status page is the source for the provider's current incident wording; compare that wording rather than relying only on the overall colored indicator.
If chat will not respond
Save your unsent prompt before refreshing. Try one short, non-sensitive message in a new conversation and record whether the problem affects that conversation too. This is a comparison, not proof of a root cause: attachment handling or a longer conversation may follow a different path.
Read the displayed message. Anthropic's chat error guidance separates usage limits, login problems and capacity constraints. A usage warning with a reset time needs different action from a failed sign-in. Capacity problems may also occur without a public incident notice. On a managed account, involve your administrator when sign-in or access policy is the failing step.
API 429 and 529 mean different things
For the direct Claude API, use the API error reference with the response body:
401: check API-key authentication in the application environment.429: inspect the rate-limit or spend-limit detail. It does not by itself establish a provider outage.500: preserve the request ID and investigate an internal API error.529: the API reports temporary overload.
Respect retry-after when supplied for rate limiting. Use bounded backoff for transient failures, and inspect the outcome of any tool action before repeating it. Retrying indefinitely will not fix a spend cap. For streamed responses, an initial HTTP 200 is not proof of completion: the stream can still contain an error.
These codes describe the direct API. If a different platform supplies your Claude model, check that platform's status and error documentation too. A working Claude chat session does not verify a third-party API deployment.
If Cowork cannot reach a file or finish a task
Inspect the failed step before launching another task. Determine whether it needs a local file, a connected service or work entirely in the cloud. Anthropic's Cowork guide explains that cloud sessions can continue independently, while access to your computer's files or browser needs Claude Desktop open and connected.
Check the selected folder or connector permissions and whether the expected computer is available. If an official notice names a particular operating system or app version, compare it with yours. A failure to access one folder does not establish that cloud execution or ordinary chat is unavailable.
Confirm recovery and share useful evidence
Recheck the original failing function, not only the homepage. For escalation, collect the product, timestamp with timezone, error message, reproduction steps and any API request ID. Remove API keys, session cookies, private prompts and customer data before sharing diagnostic material publicly.
Follow Anthropic provider alerts or review Claude incident history. Keep the incident's stated scope alongside your own observations until both indicate recovery.