Claude Went Dark for 42 Minutes on Sunday. What Would Your Phones Have Done?

At 5:58 p.m. Eastern on Sunday, August 16, one of the most widely used AI platforms in the world stopped letting users in. By 6:40 p.m. it was back. In between were roughly 42 minutes that every dealer running AI anywhere near a phone line should sit with for a moment.

Anthropic's status page logged the first notice at 21:58 UTC: users could not authenticate to claude.ai, Claude Code, and Claude Cowork. Minutes later, the company widened the incident to degraded performance across its consumer and developer surfaces. By 22:40 UTC, Anthropic confirmed all services were restored, according to reporting from BleepingComputer and the company's own status page. The developer API remained listed as operational through the incident, so many third-party products built on Claude kept running. Anthropic has not published a root cause as of this writing.

This is not a story about one vendor having a bad Sunday. It is the third high-profile infrastructure failure in ten months, and by far the shortest. The pattern - not the particular company - is the point.

Myth vs. data: The myth is that hyperscale cloud services are effectively always on. The data: a single DNS fault inside one AWS region in October 2025 drew more than 6.5 million user problem reports across 1,000-plus services worldwide, according to Cisco ThousandEyes - and full recovery took roughly 15 hours. Not minutes. Most of a business day.

Everyone's stack fails. The difference is what happens next.

Three incidents in the past ten months are worth keeping on one card:

None of these were cyberattacks. AWS traced its outage to a latent race condition in DNS automation, in the company's own post-event summary. Cloudflare's postmortem describes a database permissions change that silently doubled the size of a bot-management configuration file until its network software choked on it. These are the failure modes of ordinary complexity. Organizations with some of the best infrastructure engineers on the planet still ship a bad config eventually - which means your AI vendor, whoever it is, will too.

For a dealership, the operative question is not whether the AI behind your phones can go down. It is what a failure sounds like on the caller's end.

Your phone AI sits on a stack you cannot see

Cox Automotive's AI in Auto Retail Tracker, published August 11, found that 82% of franchised dealers already use AI somewhere in the store. A growing share of that adoption lives on the phone: AI agents answering service lines, scheduling appointments, catching after-hours sales calls.

When an AI answers your phones, the call path typically crosses at least five layers: the phone carrier, a telephony platform, the AI vendor's orchestration software, a large language model provider, and the cloud region all of it runs in. Each layer has its own availability. Availabilities multiply.

Run the arithmetic: five independent layers, each hitting a respectable 99.9%, compound to roughly 99.5% for the chain - about 44 hours a year when something, somewhere in the stack, is not working as designed. That does not mean 44 hours of dead phones; a well-built system routes around most component failures. But it does mean the raw material for a bad day exists in every AI deployment, no matter whose logo is on the invoice.

This is the same reason the model inside your AI agent matters less than the orchestration around it: the layers you never see are the product you are actually buying.

What a "99.9% uptime" promise actually buys

Uptime percentages compress badly into intuition, so it helps to translate them into hours. Over an 8,766-hour year, 99% availability permits 87.7 hours of downtime. 99.9% permits 8.8 hours. 99.99% permits about 53 minutes - roughly one Sunday incident like Anthropic's, per year, in total.

Two things follow. First, the gap between "three nines" and "four nines" is not cosmetic; it is the difference between a full business day of accumulated silence and less than one lunch break. Second, most SLA remedies are service credits - a discount on next month's bill - not compensation for the appraisal call that rang into nothing on a Saturday. The SLA tells you how confident the vendor is. It does not make you whole.

The design question that matters more than the uptime number

When an AI phone agent fails - mid-call or before it picks up - one of three things happens, and the difference between them is a design decision someone made long before the outage:

1. Invisible failover. The telephony layer detects the AI is unresponsive and rings through to staff phones or an answering pool. The caller hears a normal ring and a human voice. The outage becomes a staffing inconvenience, not a revenue event.
2. Degraded capture. The AI cannot converse, so the system falls back to voicemail plus an automatic text - not great, but the lead's number is preserved and the store can call back.
3. Silence. The call rings forever, dead-ends, or drops. The shopper calls the next store on the list. This is the outcome missed-call math already prices for you, and it is the only truly unacceptable one.

The architecture that makes option one possible is separation of failure domains: the telephony layer keeps working - and keeps routing - even when the AI brain behind it is unreachable. Think of it as the generator behind the building. You hope it never runs. You still test it.

One honest caveat belongs here, because the analyst view cuts both ways. The human baseline is not 100% either. CallRevu's data - vendor data, but drawn from monitoring dealership phone traffic at scale - shows 42% of inbound service calls going unanswered at the stores it measures. That is not an outage; it is a permanent, silent failure mode that no status page ever reports. A phone AI that fails cleanly to humans for 42 minutes a quarter still answers vastly more calls than an understaffed phone room does on an ordinary Tuesday. The case for AI on the phones survives the outage problem comfortably. It just does not survive it automatically - only deployments designed for failure do.

Eight questions to ask your AI phone vendor

A dealer does not need to audit anyone's DNS automation. These eight questions, asked before signing, do most of the work:

1. Do you publish a status page, and can I see your last 12 months of incident history?
2. Is there a written SLA? What uptime does it commit to, and what are the remedies?
3. If the model or orchestration fails mid-conversation, what does the caller experience, second by second?
4. During a full outage, where do new inbound calls go - staff ringover, voicemail-plus-text, or nowhere?
5. Are telephony and AI inference in separate failure domains, so calls can route around a dead model?
6. Can you fail over between model providers or cloud regions if an upstream provider - not you - has the bad day?
7. How will we find out about an incident: from your alerting, or from an angry customer?
8. Will you run a scheduled failover drill with us - unplug the AI on purpose and show us what callers hear?

A vendor that answers these crisply has thought about failure. A vendor that pivots back to the demo has not. The exercise pairs naturally with the security questions your AI vendor should already be answering - reliability and security diligence are the same muscle.

What to do on your side of the phone line

Four items, none requiring an engineer. Document the carrier-level forwarding override for your main numbers, so a manager can point them at a hunt group of cell phones within minutes - during a vendor outage, at the carrier, above the vendor's stack entirely. Keep a one-page manual answer protocol for whoever picks up, on paper. Watch your own miss-rate reporting during any vendor incident, because your data is the ground truth the postmortem gets checked against. And put uptime and fallback in the contract conversation with the same weight as price per call - the way human handoff design belongs there too.

The bottom line

Sunday's 42 minutes were, by infrastructure standards, a minor incident - shorter than Cloudflare's November failure by a factor of eight and AWS's October failure by a factor of twenty. The next one might not be. For dealerships whose AI deployments were designed for failure, an outage like that is a non-event: phones ring through, humans answer, the AI comes back, nobody outside the store ever knows. For deployments that were not, it is 42 minutes of ghost calls at whatever your store's cost per missed call works out to.

The difference between those two outcomes is not luck, and it is not the vendor's uptime percentage. It is whether anyone asked the failure questions before the contract was signed.

If you are evaluating what happens to your phones when - not if - some layer of the AI stack has a bad day, that resilience conversation is one Carbuki has with dealers every week.

Sources

• BleepingComputer, Anthropic confirms Claude is down in major outage affecting multiple services, Aug. 16, 2026 - bleepingcomputer.com
• Anthropic, Claude status page - status.claude.com
• AWS, Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region, October 2025 - aws.amazon.com
• Cisco ThousandEyes, AWS Outage Analysis: October 20, 2025 - thousandeyes.com
• Cloudflare, Cloudflare outage on November 18, 2025 - blog.cloudflare.com
• Cox Automotive, New Cox Automotive AI in Auto Retail Tracker Finds Growing Gap Between Dealers and AI-Powered Car Shoppers, Aug. 11, 2026 - coxautoinc.com
• CallRevu, The Phone Call Is the Moment, April 22, 2025 - callrevu.com