Claude outage: models failed one at a time, not all at once

The Claude outage on 30 July 2026 is worth reading closely, not because Claude went down, but because of how it went down. Anthropic's own incident page, Elevated errors across many models, shows models recovering and re-breaking in sequence over roughly two and a half hours.

If your app hardcodes one model ID, that pattern is the whole story. Most of the time there was a working model available. Your code just wasn't allowed to reach for it.

---

🔍 What the status page actually says

The incident is titled "Elevated errors across many models" and lists four affected surfaces: claude.ai, the Claude API (api.anthropic.com), Claude Code, and Claude Cowork. Here is the published update timeline, with Sri Lanka time added (UTC+5:30):

UTC	Sri Lanka time	Update
05:57	11:27	"We are currently investigating this issue."
06:26	11:56	All models except Opus 5 recovered
07:33	13:03	Opus 5 back to baseline, Sonnet 5 errors up again
08:06	13:36	Sonnet 5 back to baseline, Fable 5 error rate rising
08:33	14:03	"back to errors across all models"

Two honest caveats. The Hacker News headline that carried this story called it a second consecutive day of downtime; the incident page I read only documents 30 July, so treat the multi-day framing as unverified. And "elevated errors" is not the same as a hard outage. Some requests were still going through.

Key takeaway: For most of that window, at least one Claude model was healthy. An app pinned to a single model ID experienced a total outage. An app that could fall back across models experienced a slow day.

---

⚡ Why per-model failure is the useful detail

We tend to think about provider reliability as a binary: the API is up, or it is down. This incident shows a third state that is far more common in practice — partial capacity, where one model family is degraded and the others are fine. Four consequences follow:

1. A single model ID is a single point of failure, even inside one healthy provider.
2. Retrying the same model harder makes it worse. If Opus 5 is the degraded one, exponential backoff against Opus 5 just burns your rate limit budget slowly instead of quickly.
3. Status pages lag reality. The first update landed at 05:57 UTC, after errors had already started. Your own error rate is a faster signal than anyone's status page.
4. The failure moved. Recovering to "Sonnet is fine now" and hardcoding that would have broken you again 33 minutes later.

If you are unsure which model IDs are current and spelled correctly for fallback, our AI model ID cheatsheet lists them per provider.

---

🛠️ A fallback ladder you can write in ten minutes

You do not need a service mesh for this. You need an ordered list and a loop. The important part is that the ladder crosses model tiers first, then providers, and gives up quickly rather than hanging.

const LADDER = [
  { provider: "anthropic", model: "claude-sonnet-5" },
  { provider: "anthropic", model: "claude-opus-5" },
  { provider: "anthropic", model: "claude-haiku-4-5-20251001" },
  { provider: "other",     model: "<your second provider>" },
];

async function ask(prompt) {
  let lastErr;
  for (const step of LADDER) {
    try {
      return await call(step, prompt, { timeoutMs: 20_000, retries: 1 });
    } catch (err) {
      lastErr = err;
      if (err.status === 400 || err.status === 401) throw err; // your bug, not theirs
      // 429 / 500 / 503 / 529 / timeout → fall through to next rung
    }
  }
  throw lastErr;
}

Three rules that make the difference between a ladder that helps and one that hurts:

• Do not retry 4xx. A malformed request fails identically on every rung. Only overload, rate-limit, server-error and timeout conditions should advance the ladder. If you are not sure which code means what, the AI API error code lookup is exactly this reference.
• Cap the total time, not the per-call time. Four rungs at 20 seconds each is 80 seconds of a user staring at a spinner. Budget the whole operation.
• Keep prompts portable. If your prompt only works with one provider's tool-call format, your ladder stops at that provider's edge. Converting between formats is mechanical — see the Anthropic to OpenAI converter if you need a starting point.

---

📊 What a 2.5-hour incident does to an uptime promise

If you have told a client you deliver "99.9% uptime", it is worth knowing what you actually signed up for. Over a 30-day month (43,200 minutes):

Target	Allowed downtime / 30 days
99%	7 hours 12 min
99.5%	3 hours 36 min
99.9%	43.2 min
99.95%	21.6 min
99.99%	4.3 min

The published window in this single incident runs from 05:57 to 08:33 UTC — 2 hours 36 minutes, and the last update says errors were back across all models rather than resolved. One incident like that alone breaks a 99.9% month more than three times over. You can run your own numbers with our uptime SLA calculator.

The practical fix is not to promise less. It is to promise on your own service, not the model's. "Your document will be processed within 30 minutes" is a promise a queue can keep. "Instant AI response, always" is a promise you are subcontracting to someone else's capacity planning.

---

💡 The part that hits harder from Sri Lanka

Look at the local times again: this landed between 11:27 and 14:03 Sri Lanka time. Mid-workday. Not a quiet 3am window where you could ship a fix before anyone noticed.

A few things follow from that, if you build here:

• You are downstream of a business-hours-elsewhere schedule. Incidents that start at 06:00 UTC land at lunchtime for you and get their fixes during someone else's morning.
• Free-tier and student accounts are usually shed first when capacity is tight. If you are on a free tier for a university project deadline, you feel these events more sharply than a paying enterprise does.
• A local model is a real backstop. A small model running on your own machine will not match Opus 5, but "degraded answer now" beats "no answer for three hours" for classification, extraction and summarisation work. If you are sizing what your laptop can actually hold, the LLM VRAM calculator will tell you in about ten seconds.
• Cache aggressively. Every identical prompt you serve from cache is a request that cannot fail during an incident.

Bottom line: Design for partial capacity, not for binary up/down. Partial capacity is the state you will spend the most hours in.

---

What this means for you

If you ship anything built on an LLM API, do these four things this week:

1. Replace your single model constant with an ordered ladder. Half an hour of work.
2. Classify your errors properly — retry overload and timeouts, never retry a 400.
3. Add a visible degraded state to your UI. "Running on a backup model, answers may be shorter" keeps users' trust far better than a spinner that never resolves.
4. Re-read your own uptime claims and move them onto something you control, like a queue with a delivery window.

None of this is about Anthropic specifically. Every provider has these days. The only difference between teams is whether the incident shows up as an outage or as a slightly slower afternoon.

Facts in this post come from the Claude status page incident linked above. Everything else is my own reading of it.