Claude outage, 13 November 2026: what broke, what Anthropic said, and how to keep your app working
On 13 November 2026 Claude went down twice. Both outages are over: when I checked at 04:51 UTC on 14 November, Anthropic's status page said all systems were operational. From 09:58 UTC (15:28 in India) people had trouble signing in to claude.ai and Claude Code for about two hours, and the Console was listed as affected too. From 13:09 UTC a second, wider outage brought errors to claude.ai, the Claude API, Claude Code and the connectors for another two and a half hours. This page sets out what Anthropic's status page said, what each outage did and did not touch, how often Claude has had incidents over the last 92 days, and how to build your own app so the next one does not take it down with it. I tested the last part with Anthropic's real Python SDK.
This explainer covers one piece of news. The AI Engineering course teaches how systems like this work, step by step.
1Status when this page was written (04:51 UTC, 14 November 2026): Anthropic's status page said "All Systems Operational" and every incident below was marked resolved. Anthropic has not published a cause for either outage.
2First outage, 09:58 to 11:58 UTC on 13 November: Anthropic reported an issue with users signing in to claude.ai and Claude Code. It listed claude.ai, Claude Code, the Console (the developer site for API keys and billing) and Cowork (Claude's desktop agent for longer tasks) as affected, but not the Claude API. It deployed a fix at 11:05.
3Second outage, 13:09 to 15:38 UTC: errors on claude.ai, the mobile apps, the Claude API, Claude Code and connectors such as Docs and Sheets. claude.ai and the API were recovering by 14:36. Anthropic said scheduled tasks and routines could run more than two hours late and some runs were skipped.
4Two more incidents sat around them: the Microsoft 365 connector failed for about a day because of Microsoft's own outage, and on 14 November purchases and plan changes on claude.ai failed for 89 minutes. Anthropic said nobody who paid needed to pay again.
5Over the last 92 days Anthropic's status page shows 47 incidents of minor impact or worse, and 23 of them name one model or several. The design lesson, from our test with Anthropic's real SDK: retries alone only make each failure slower. A second route kept every call answered, and a circuit breaker (code that stops calling a failing service for a short while) made the whole batch about 40 times faster.
First outage
13 Nov, 09:58-11:58 UTC, sign-in
Second outage
13 Nov, 13:09-15:38 UTC
India time
15:28 and 18:39 IST
Claude API listed
Second outage only
Cause
Not published
Last checked
04:51 UTC, 14 Nov
This page is the free part.
The course goes deeper on reliability for LLM apps: retries, circuit breakers and provider failover
₹1,333 in India/$35 everywhere elseonce, for the whole course
The Generative AI and Agentic AI course covers reliability for LLM apps: retries, circuit breakers and provider failover across a run of lessons, not one page. These 3 alone are about 265 minutes of step-by-step reading, every one with code you run in the browser, all with a quiz.
HTTP 429 is the first failure an LLM app hits at scale. Beat rate limits and provider outages with token buckets, backoff, degraded modes, and failover.
Uptime cannot measure a system that answers wrong while healthy. Define a quality SLO, run an error budget on the pass rate, and degrade to honest fallbacks.
“Scheduled tasks and routines can run more than two hours late and some runs have been skipped, and Claude Security scans, reviews and project setup remain delayed.”
Anthropic, status.claude.com, update at 15:33 UTC on 13 November 2026
On Friday 13 November 2026, at 09:58 UTC, Anthropic opened an incident on its status page: "We are investigating an issue with users authenticating to Claude.ai and Claude Code." In India it was 15:28; on the US East Coast, 04:58 in the morning. Anthropic also listed the Console and Cowork as affected. Twenty-one minutes later a thread titled "Claude Is Down" was posted on Hacker News. At 11:05 UTC Anthropic said a fix had been deployed, and at 11:58 it marked the incident resolved.
An hour later it happened again, wider. At 13:09 UTC Anthropic reported degraded performance on claude.ai, the Claude API and Claude Code. By 14:03 the list had grown to connectors (including Claude Docs and Claude Sheets), Claude Security and Claude Managed Agents. At 14:36 claude.ai and the API were recovering, with a warning that errors might return. At 15:33 errors were back to normal levels, with some leftovers: adding a new connector was temporarily unavailable, scheduled tasks and routines could run more than two hours late and some had been skipped, and Claude Security scans were delayed. The incident was marked resolved at 15:38.
Anthropic did not say what caused either outage, or whether the two were connected. Everything on this page about the timing of the outages comes from its status page, which I saved and parsed on the morning of 14 November.
Two Claude outages in one day, while a third problem came from Microsoft
Each bar is the time an incident was open on Anthropic's status page. The numbered dots are the updates Anthropic posted, with UTC and India times underneath.
If Claude stops answering in the middle of your work, these are the practical steps, based on what Anthropic's status page and documentation say.
Check status.claude.com before you change anything. It lists each surface separately: claude.ai, Claude Code, the Console, the Claude API and the cloud platforms. If your surface is listed, the problem is on Anthropic's side; reinstalling, logging out or changing settings will not help.
Save your work outside the chat. Copy any long answer or plan you need into a file. Claude Code edits files on your disk as it goes, so after an outage run git status and git diff to see exactly what changed before you continue, and commit or stash what you want to keep.
If only sign-in is broken, an API key may still work. In the first outage Anthropic did not list the Claude API as affected. Claude Code can run on a Console API key (ANTHROPIC_API_KEY) or on Amazon Bedrock or Google Cloud credentials instead of a claude.ai login; its documentation gives the order it picks them in. Create the key before you need it, because the Console was affected too. I could not test this during the outage, so treat it as a plan to try, not a promise. If you set ANTHROPIC_API_KEY, remove it once sign-in works again, or Claude Code will keep billing your API account.
If one model is failing, try another. About half of Claude's incidents over the last 92 days named one or more models (17 named particular models). When the status page says "Elevated errors for" one model, switching to another Claude model is often the quickest way back to work.
After it is fixed, check scheduled work. Anthropic said some scheduled tasks and routines were skipped during the second outage. Look for runs that should have happened between 13:09 and 15:38 UTC and start them again by hand.
Paid during the purchase incident? Do not pay again. For the purchase failures on 14 November, Anthropic said delayed plan changes and payments were applied after the fix, and that there was no need to pay again.
3
What each outage touched, and what it did not
Anthropic's status page marks which parts of Claude each incident affected. Read side by side, the four incidents of 12 to 14 November tell different stories.
The morning outage was about signing in. Anthropic listed claude.ai, Claude Code, the Console and Cowork, all things a person logs in to. It did not list the Claude API, which programs call with an API key and no login. So a product that called the API from its own servers may have kept working that morning while the people building it had trouble signing in to their tools. The afternoon outage listed the API as well, so that time products were hit too.
The Microsoft 365 connector incident had a different cause altogether: Anthropic's own words were that it "is caused by a Microsoft 365 service incident". Claude was working, but the Microsoft service it reads mail and calendars from was not. That is the same Microsoft outage covered on this site's Microsoft 365 page, and it shows that your AI provider's uptime also depends on everything it connects to.
The morning outage was trouble signing in to the apps, but Anthropic did not list the API
A filled square means Anthropic listed that surface on the incident. A missing square is what Anthropic posted, not proof that every request worked. The two cloud rows were only added to the status page on 9 November.
Both courses together: ₹1,999 in India / $49 elsewhere, lifetime access.
System Design and AI Engineering in one payment. Bought one by one: ₹1,111 + ₹1,333 = ₹2,444, so you save ₹445.Bought one by one: $25 + $35 = $60, so you save $11.
Anthropic's status page keeps its last 50 incidents. On 14 November they reached back 92 days, to 14 August 2026. Leaving out three marked as having no impact, that is 47 incidents of minor impact or worse, 29 of them major or critical. The figures count incidents as opened and closed on the status page; that is the time Anthropic was posting about a problem, which is close to but not the same as the time users were affected.
The interesting part is what broke. I sorted each incident by its title and, where the title was generic, by Anthropic's first update. 23 of the 47 name a model: "Elevated errors for Claude Sonnet 5.5", "Elevated errors for Claude Fable 5.1", or "multiple models". Eight were the apps or the platform, seven were connectors to other services, five were billing or purchases and four were about signing in. In the same 92 days Anthropic listed the Claude API on 29 incidents, Claude Code on 33 and claude.ai on 39.
This matters for design, because the cure depends on the kind of failure. When one model is failing, falling back to a different Claude model on the same API can be enough. When sign-in or the whole platform fails, as on 13 November, every model behind that door is out of reach at once, and only a route that does not go through the same door helps.
47 incidents in 92 days, and about half were a model failing, not the whole service
Every incident on status.claude.com from 14 August to 14 November 2026 of minor impact or worse, grouped by what its title (or, for a generic title, Anthropic's first update) says broke. The sorting is mine and is in history.py.
My hands-on: what Anthropic's SDK does when the API is down
Many products call Claude through Anthropic's official SDK, so I wanted to know exactly what it does on its own when the API is overloaded, and what a little extra code changes. I could not test against the real outage, which was over, and I did not want to load Anthropic's API on purpose. So I installed the real anthropic package from PyPI (version 2.8.0) and pointed it at two small servers on my own machine. One answers every request the way an overloaded API does, with HTTP 529 and an overloaded_error, the response Anthropic's error docs describe. The other answers every request normally, standing in for a second route.
Out of the box, the SDK tries each call three times: the first try and two retries, waiting about half a second and then about a second, slightly randomised. Over five runs that made each failed call take 1.38 to 1.49 seconds before it gave up and raised an OverloadedError. If the server sends a retry-after header, the SDK waits exactly as long as it says: with retry-after: 20, one failed call took 40 seconds. And if a server takes the connection but never answers, every try waits for the full timeout, which by default is ten minutes; with a 3-second timeout, three tries took 10.6 seconds.
Then I sent 20 calls in a row, three ways. With the default client and no fallback, none of the 20 were answered, the dead route took 60 calls and the batch took 29 seconds. Adding a fallback after the SDK gives up answered all 20, but still hit the dead route 60 times and still took 29.6 seconds, because every call first waits through its three tries. With a circuit breaker, which stops calling the main route after three failed calls in a row and sends work straight to the second route for 30 seconds (with the SDK's own retries switched off on that route, max_retries=0, so the breaker sees each failure at once), all 20 were answered, the dead route got only 3 calls, the median call took 0.026 seconds and the whole batch took 0.72 seconds.
The SDK's retries are a good default: most errors are brief, and a retry half a second later often works. The SDK also respects retry-after, which lets an overloaded server ask clients to back off. The problem is only that retries cannot tell a blip from an outage. A circuit breaker can, because it remembers: after a few failures in a row it stops trying for a while, and after the pause it tries the main route again. In my test the 20 calls finished long before the 30-second pause ended, so that second step was not exercised. If you keep the SDK's default retries on the main route, three failed calls are nine requests, not three.
What we measured: 14 November 2026, the anthropic Python SDK 2.8.0 on Python 3.14.7, against two stub HTTP servers on 127.0.0.1. Nothing was sent to Anthropic and no real key was used; times include only local work and the SDK's own waits. Full output in data/sdk-retry-out.txt.
$ python sdk_retry_probe.py
anthropic 2.8.0, Python 3.14.7
SDK defaults: max_retries=2, timeout=Timeout(connect=5.0, read=600, write=600, pool=600)
== 1. default client vs HTTP 529 overloaded_error (5 runs)
run 1: attempts 3, gaps [0.472, 0.865] s, total 1.40 s, raised OverloadedError 529
run 2: attempts 3, gaps [0.522, 0.894] s, total 1.42 s, raised OverloadedError 529
== 2. HTTP 529 with retry-after: 20
attempts 3, gaps [20.073, 20.059] s, total 40.14 s
== 3. server accepts the connection and never answers, timeout=3 s
attempts 3, total 10.59 s, raised APITimeoutError
== 4. 20 calls in a row while the primary returns 529 and a second route is healthy
a. default client, primary only answered 0/20, calls to primary 60, median 1.436 s, total 28.98 s
b. default client, then fall back answered 20/20, calls to primary 60, median 1.487 s, total 29.57 s
c. breaker + fallback answered 20/20, calls to primary 3, median 0.026 s, total 0.72 s
Real output of sdk_retry_probe.py, shortened: runs 3 to 5 of test 1 (1.38 to 1.49 s) and some columns of test 4 are cut for space. The script and the circuit breaker it uses are in scripts/labs/claude-outage.
Retrying a provider that is down only makes each failure slower; a circuit breaker and a second route fix it
Measured with the real SDK against local stubs. The SDK's two retries are right for a short blip, but in a two-hour outage they turn every call into three calls and a wait.
Circuit breakers, retry patterns with backoff and budgets, bulkheads, graceful degradation and incident management, each as its own lesson with diagrams and a quiz.
770 lessons, beginner to principal
107 real interview systems taken apart step by step
An AI tutor beside every lesson that answers and draws
How to design your app so a Claude outage does not take it down
If your product calls Claude, the next outage will come; 47 incidents in 92 days is roughly one every two days. About half named one or more models, and 21 of the 47 were closed within an hour. These are the safeguards worth adding, in the order I would add them.
Set a timeout you can live with. The SDK's default timeout is ten minutes, and it retries twice. For a chat reply your users are watching, set a timeout of seconds, not minutes, and use streaming so you see the first token early.
Put a circuit breaker in front of each route. After a few failures in a row, stop calling that route for a short time and fail fast instead. In our test, with the SDK's retries switched off on that route, it cut calls to the dead route from 60 to 3 (it would be 9 with the default retries) and the batch from 29 seconds to under one.
Fall back to another model first. About half of Claude's incidents named a model. A cheaper or older Claude model on the same API is the simplest fallback. Run it through the same tests as your main model before you rely on it, because its answers and formatting will differ.
Keep a second route that does not share the first one's front door. When sign-in or the whole platform fails, every model behind it fails together. Amazon Bedrock and Google Cloud both sell Claude, and on Bedrock, AWS runs the serving stack itself, according to Anthropic's docs. Note that Claude Platform on AWS and Claude Models on Google Cloud (Anthropic managed) are both run by Anthropic, so they are different doors to the same house. Set the second route up and test it before you need it; enabling model access during an outage is too late. Some teams also keep a different provider's model ready for their most important feature.
Decide what the screen shows when every route fails. A saved answer, a short message, or the rest of the page without the AI panel. Graceful degradation is a product decision; make it before the outage, not during it.
Do not let retries pile up. Cap retries with a budget, for example stop retrying when more than one call in ten is already a retry, and respect retry-after. Thousands of clients retrying at once are part of what keeps an overloaded service down.
Make scheduled jobs safe to run twice. Anthropic said some scheduled runs were skipped on 13 November. Jobs you can rerun without side effects, with a record of which ran, make catching up after an outage a five-minute job.
Most of these are taught in the courses: provider failure, failover, routing and cascades in AI Engineering, and circuit breakers, retry budgets, bulkheads and graceful degradation in System Design.
Every timestamp, quote and component list on this page comes from Anthropic's status page, read through its public JSON at status.claude.com on 14 November at 04:51 UTC and saved in the lab folder. The facts about the SDK, Claude Code sign-in and the cloud platforms come from Anthropic's own documentation, saved the same morning. I did not use news reports for any fact; the Hacker News thread is cited only for when the discussion started (its item data is saved too).
What I could not check: why either outage happened, which Anthropic has not said, and how many people were affected. A surface that the status page did not list may still have had some errors. The test of the SDK is real code against local stand-in servers, so it measures what the client does, not how Anthropic's servers behaved. I will update this page if Anthropic publishes a cause.
if this explainer was useful
Want your AI features to keep answering when the model provider has a bad day?Start with Generative AI and Agentic AI.
start here
Generative AI and Agentic AI Engineering
Rate limits and provider failure, model routing and cascades, and reliability for systems whose answers vary, each as a lesson with code you can run.
219 lessons in 17 chapters: RAG, AI agents, evals, fine-tuning and serving
No heavy maths, everything taught step by step from the basics
127 lessons built on a lab that really ran
An AI tutor beside every lesson that answers and draws
Circuit breakers, retry patterns with backoff and budgets, bulkheads, graceful degradation and incident management, each as its own lesson with diagrams and a quiz.
770 lessons, beginner to principal
107 real interview systems taken apart step by step
An AI tutor beside every lesson that answers and draws
Both courses together: ₹1,999 in India / $49 elsewhere, lifetime access.
System Design and AI Engineering in one payment. Bought one by one: ₹1,111 + ₹1,333 = ₹2,444, so you save ₹445.Bought one by one: $25 + $35 = $60, so you save $11.
Where does reliability for LLM apps: retries, circuit breakers and provider failover fit in a real system?
Knowing what it is comes first. Knowing where it fits, and what breaks around it, comes next. The lessons below teach that, starting with "Rate Limits and Provider Failure: The Number One Production Error".
The lessons that teach the next part
HTTP 429 is the first failure an LLM app hits at scale. Beat rate limits and provider outages with token buckets, backoff, degraded modes, and failover.
Uptime cannot measure a system that answers wrong while healthy. Define a quality SLO, run an error budget on the pass rate, and degrade to honest fallbacks.
When this page was written, at 04:51 UTC on 14 November 2026, Anthropic's status page said all systems were operational. For the live answer, check status.claude.com, which lists claude.ai, Claude Code, the Console, the Claude API and the cloud platforms separately.
Why was Claude down on 13 November 2026?
Anthropic has not published a cause. Its status page shows two outages: a sign-in problem on claude.ai and Claude Code (the Console and Cowork were also listed) from 09:58 to 11:58 UTC, and wider errors on claude.ai, the Claude API, Claude Code and connectors from 13:09 to 15:38 UTC.
What time was the Claude outage in India?
The first outage began at 15:28 IST and was resolved at 17:28 IST. The second began at 18:39 IST and was resolved at 21:08 IST, on 13 November 2026.
Was the Claude API affected?
Not in the first outage, according to Anthropic's status page, which listed only claude.ai, Claude Code, the Console and Cowork. The second outage listed the Claude API, and Anthropic said it was recovering by 14:36 UTC.
Did Claude Code lose my work?
Claude Code edits files on your own computer, so anything it had already written is still on disk. A task cut off halfway may have left some files changed and others not. Run git status and git diff to see what changed before you carry on.
I paid for a Claude plan early on 14 November and it did not update. Should I pay again?
No. For the purchase incident from 02:34 to 04:03 UTC on 14 November, Anthropic said delayed plan changes and payments had been applied and that there was no need to pay again.
How often does Claude go down?
Anthropic's status page shows 47 incidents of minor impact or worse in the 92 days to 14 November 2026, 29 of them major or critical. About half named one model or several rather than the whole service, and many lasted under an hour.
How do I keep my app working when Claude is down?
Set a short timeout, put a circuit breaker in front of each route, fall back first to another Claude model and then to a route whose serving is run separately, such as Amazon Bedrock, set up and tested in advance, and decide what your screen shows when everything fails.
Sources
What this explainer is based on, so you can check it.
This explainer sits on top of our AI Engineering course: 219 lessons on RAG, evals, agents, serving, security and MLOps, many built around a real experiment. 10 lessons are free to read, with no card needed.
course 2
Generative AI and Agentic AI Engineering
Build RAG apps, AI agents and LLM systems. No heavy maths, taught from the basics, with labs on real models.
219 interactive lessons
RAG, AI agents, evals and fine-tuning
Serving, pipelines, feature stores and monitoring
Step-by-step diagrams and quizzes
Lifetime access and all future lessons
Sold on its own, or with System Design in one payment
Get all 150 questions in the AI Engineering (LLM applications) pack
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (180 diagrams in all). A PDF you keep, junior to staff level.
