AI & Product
The Claude outage of 13 November 2026, and why our clients' systems kept running
Published
On this page
On Friday 13 November 2026, Anthropic’s status page logged two incidents. The first ran from 09:58 to 11:58 UTC and stopped people signing in to claude.ai and Claude Code. The second ran from 13:09 to 15:38 UTC and brought elevated errors to claude.ai, the mobile apps, Claude Code and the Claude API. That is 4 hours 29 minutes of incident time inside one working day.
If you spent part of that day looking at a login screen, you had company. “Is Claude down” is searched about 62,000 times a month in the US, going by Ahrefs.
We build software for clients that runs on Claude. None of them reported a problem on the 13th. The reason is mostly about which part of Claude their systems depend on, and it is worth going through carefully, because the simple version (“the API never goes down”) is wrong.
What the status page shows
Friday 13 November 2026, by component
| Incident | Time (UTC) | Length | Listed as affected |
|---|---|---|---|
| Sign-in failures | 09:58 to 11:58 | 2 h 00 min | claude.ai, Claude Console, Claude Code, Claude Cowork |
| Elevated errors | 13:09 to 15:38 | 2 h 29 min | claude.ai, Claude API, Claude Code, Claude Cowork |
The first incident was about authentication. Anthropic’s first note says it was investigating “an issue with users authenticating to Claude.ai and Claude Code”. The Claude API is not on that list. A system that calls the API does so with a key. It never goes through the sign-in flow, so there was nothing in it to fail.
The second incident did include the API. At 14:36 UTC Anthropic reported recovery on claude.ai and the API. Connectors, Claude Managed Agents and Claude in Meetings were still degraded at that point. At 15:33, five minutes before the incident closed, the update said scheduled tasks could run more than two hours late and that some runs had been skipped.
So the API was in one incident out of two, and it recovered ahead of the features built on top of it.
The app has more parts
When you open claude.ai and ask it to draft a reply using your calendar, several things have to work at once: your login session, the web or mobile app, the connector to your calendar, the calendar provider on the other side, and the model. A direct API call needs a key and the model.
In the app5 parts
- Sign-in session
- Web or mobile app
- Connector
- Third-party service
- Model
On the API2 parts
- API key
- Model
More parts means more ways to have a bad afternoon. Some of those parts are not Anthropic’s. The Microsoft 365 connector returned errors from 16:03 UTC on 12 November to 16:40 UTC on 13 November because of an incident at Microsoft. In October the Google Calendar connector was affected from the 26th to the 28th.
Here are the monthly uptime figures Anthropic publishes, read on 14 November:
| September | October | November to date | |
|---|---|---|---|
| claude.ai | 99.69% | 99.85% | 98.42% |
| Claude Code | 99.69% | 99.85% | 99.66% |
| Claude API | 99.73% | 99.86% | 99.77% |
Share of November unavailable, 1 to 14 November 2026
September and October are close to identical, and we would not build an argument on them. November is where the difference shows. If about thirteen and a half days of the month had passed when we read the page, 98.42% works out to roughly five hours of unavailability for claude.ai, and 99.77% to under one hour for the API. We’ll see how the rest of the month goes.
What changes when you build on the API
The uptime figure is only part of it. The bigger difference is who decides what happens when a request fails.
In the app, you wait. There is nothing else to do.
In a system built on the API, that decision is written into the software. A failed request can be tried again after a short pause; Anthropic’s own SDKs retry twice by default. Work can sit in a queue until the service is back. Requests can be sent to the same Claude models on AWS, Google Cloud or Microsoft Foundry, which are tracked separately on the status page and were not listed in either incident on the 13th.
That is what our clients’ systems are built on. The first incident never reached them. In the second, the API was listed for part of the window, and still no client reported a disruption.
It would be dishonest to stop there. The API has bad days too. On 29 September an incident hit everything, the API included, with impact from 14:00 to 14:59 UTC. Building on the API also costs more at the start. Someone has to write the software, you pay per request instead of a flat subscription, and it needs looking after. For a lot of work that cost buys nothing you need.
The 4 hours 29 minutes question
Most businesses use Claude through the app, and for most of what they do with it that is the right call. It is cheaper, it needs no engineering, and it gets new features first.
A useful test is to take the number from the 13th and ask what it would cost you. Suppose Claude is unavailable for 4 hours 29 minutes on a weekday.
What would it cost you?
Put in your own numbers. Nothing is sent anywhere.
- Person-hours waiting
- 22.4
- Cost of the waiting
- 897
Nobody outside the company is affected. The app is the right choice for this work.
Show us this processIf the answer is that people work on something else and catch up later, stay where you are. An integration would be money spent on a problem you do not have.
If the answer involves a customer, it is different. Support replies that do not go out. Orders or documents that stop being processed. A report a client is waiting for. Work like that should not depend on a person being signed in to a chat window, and it is the kind of work that is usually moved to the API.
It does not have to be everything. Moving one process, maybe two, is often enough, and the rest of the team carries on in the app as before.
A practical way to start: write down what your business does with Claude each week, and put a mark next to anything a customer would notice if it stopped for an afternoon. If the list has no marks, you are done. If it has one, that is the process to look at, and we are happy to look at it with you. It falls under our custom software work.
The incident pages for 13 November are on status.claude.com if you want to check the times yourself.