Anthropic API Status: How to Check It and What to Do

Where to check Anthropic API status

If you're seeing errors, slow responses, or failed requests from Claude and want to know whether it's your code or Anthropic's infrastructure, the first stop is status.anthropic.com. This is Anthropic's official status page, and it tracks uptime and incidents for the API, the Claude.ai web app, and related services separately. Each component shows one of a few states — operational, degraded performance, partial outage, or major outage — along with a timeline of past incidents and their resolution.

The second thing worth knowing: API status pages report known, confirmed incidents. If you're getting intermittent errors that aren't yet reflected on the status page, that doesn't mean the problem isn't real — it usually means the issue is either too small to trigger an official incident, specific to a region or model, or still being triaged. In practice, many developers see elevated error rates or 529 overloaded responses for several minutes before the status page updates. So checking status is useful, but it shouldn't be your only signal — your own error handling and retry logic matter just as much.

What the different status states actually mean

• Operational — everything is working within normal parameters. Latency and error rates are at baseline.
• Degraded performance — the API is responding but slower than usual, or a subset of requests are failing. This is the most common non-operational state and often resolves within 15–60 minutes.
• Partial outage — a specific component (a particular model, a specific region, or a feature like tool use) is failing while the rest of the API works fine.
• Major outage — the API is largely unavailable. These are rare but do happen, usually tied to upstream infrastructure issues or major traffic spikes after a new model release.

Anthropic also documents typical error codes you'll encounter during degraded periods, most commonly 429 (rate limited) and 529 (overloaded). Distinguishing between "the whole API is down" and "I'm being rate limited" matters because the fix is completely different — one needs waiting for Anthropic, the other needs you to slow down your own request rate.

Why status matters more if you're running production traffic

For a side project, checking the status page manually when something breaks is fine. For anything customer-facing, you need three things in place before an incident happens, not during one:

1. Automated retries with exponential backoff for transient errors (429, 529, timeouts).
2. A way to distinguish your bugs from upstream incidents — logging status codes and response bodies, not just "request failed."
3. A plan for what your app does when Claude is genuinely unavailable — a queued retry, a user-facing message, or a fallback path.

Here's a minimal retry pattern that handles the common transient failure modes:

async function callClaude(payload, attempt = 1) {
  const res = await fetch("https://api.anthropic.com/v1/messages", {
    method: "POST",
    headers: {
      "x-api-key": process.env.ANTHROPIC_API_KEY,
      "anthropic-version": "2023-06-01",
      "content-type": "application/json",
    },
    body: JSON.stringify(payload),
  });

  if (res.status === 429 || res.status === 529) {
    if (attempt > 5) throw new Error("Claude API unavailable after retries");
    const delay = Math.min(1000 * 2 ** attempt, 30000);
    await new Promise((r) => setTimeout(r, delay));
    return callClaude(payload, attempt + 1);
  }

  if (!res.ok) throw new Error(`Claude API error: ${res.status}`);
  return res.json();
}

This handles the most common causes of "the API seems down" without you having to manually watch a status page every time something goes wrong.

If your app calls Claude through SubToAPI

If you access Claude through SubToAPI rather than calling Anthropic's API directly, the same principles apply, but you get a few practical advantages. SubToAPI issues application-scoped keys (sub_live_...) so you can isolate traffic per app or per environment, which makes it much easier to tell whether an outage is affecting one integration or all of them. The Messages API and streaming endpoints return the same structured error responses you'd expect, so your existing retry logic doesn't need to change.

The dashboard also gives you usage metadata per key, which is genuinely useful during a suspected outage — if request volume and error rates for one key spike while others stay flat, you know the problem is scoped to that integration rather than a broad Claude issue. Getting started takes a few minutes: see the quickstart guide if you're setting this up for the first time, or sign up to try it with the free trial.

A simple checklist for "is the API down or is it me"

When something breaks, work through this in order:

1. Check status.anthropic.com for the API component specifically (not just Claude.ai).
2. Check the HTTP status code you're getting — 429/529 point to rate limiting or overload, not a full outage.
3. Test the same request with curl directly, stripping out your app's abstraction layers.
4. Check whether it's model-specific — try a different Claude model if you have access to more than one.
5. If you're behind a proxy or gateway (including SubToAPI), check that dashboard's own status alongside Anthropic's, since an issue can exist at either layer.

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 100,
    "messages": [{"role": "user", "content": "ping"}]
  }'

If this bare-bones request fails the same way your app does, it's almost certainly upstream. If it succeeds while your app still fails, the bug is in your code, not Anthropic's infrastructure.

questions

Where can I check Anthropic API status right now? Go to status.anthropic.com. It shows live status for the API, Claude.ai, and related components, plus a history of past incidents with timestamps and resolutions.

What does a "529" error mean and is that a status page issue? A 529 means the API is temporarily overloaded and rejecting your request. It often precedes a "degraded performance" update on the status page — retry with exponential backoff rather than immediately assuming a full outage.

Does an Anthropic outage affect apps built on SubToAPI too? Yes, since SubToAPI routes requests to Claude — if the underlying API is down, requests through SubToAPI will fail the same way. Checking both the Anthropic status page and your SubToAPI dashboard usage helps you confirm where an issue is actually occurring.