Contents
Between March 2 and 3, 2026, Claude surfaces (web/app) went through a sequence of closely spaced degradations and incidents — failed logins, elevated errors, then a model-specific incident on Opus 4.6. The business risk is not only "the AI gets things wrong" — it is also "the AI becomes unavailable." Here is the timeline, the benchmark against OpenAI and Google, and a concrete multi-model resilience plan.
Executive summary
On March 2, an incident labeled "Elevated errors on claude.ai, console, and claude code" began at 11:49 UTC and was marked resolved at 15:47 UTC, for a total duration of about 3 hours and 58 minutes. The update thread notably stated that "the API is working as intended" while the issues were "related to Claude.ai and the login/logout paths," then later mentioned that "some API methods are not functioning" during the investigation.
On March 3, a new incident, "Elevated errors in claude.ai, cowork, platform, claude code," was posted at 03:15 UTC, then moved to monitoring at 08:39 UTC, with another update at 09:36 UTC stating "we continue to monitor," without a "Resolved" status at that time. In parallel, a model-specific incident, "Elevated errors on Claude Opus 4.6," was posted at 06:59 UTC, moved to Identified at 08:31 UTC, and then to Monitoring at 10:27 UTC, affecting claude.ai, platform.claude.com, Claude API, and Claude Code.
On the external signal side, multiple media sources converged on two structural points: first, the incident was highly visible to the general public, especially around login, interface access, and conversation history; second, it occurred in a context of rising demand. TechCrunch reported that the most common error was a login failure and that the API was shown as "working as intended." Bloomberg quoted a statement referring to "unprecedented demand" and noted that "consumer-facing surfaces" were offline, while business integrations were said to be unaffected — a point that should be interpreted cautiously in light of the status updates. In France, MacGeneration and Les Numériques also described an outage affecting claude.ai, Claude Code, and the platform, with a strong emphasis on connection issues and partial service disruption.
Business implication: the main risk is not only "the AI gets things wrong," but also "the AI becomes unavailable or degraded," often because of very classical factors — authentication, load spikes, and configuration propagation. Public postmortems published elsewhere, notably by OpenAI and Google, show that configuration changes and retry loops can amplify a failure if client architecture is not protected by appropriate safeguards. Integrating AI capabilities into web applications now requires real resilience engineering discipline: SLOs/SLAs, observability, multi-model routing, and incident playbooks.
What this incident reveals
The phrase "Claude AI down" actually covers multiple surfaces and multiple failure modes.
- Surface outage (login/UI/history): when login/logout flows or session handling break, the user perception is often "everything is down," even if inference endpoints or certain API calls remain partially available — explicitly reflected in the March 2 update ("issues related to Claude.ai and with the login/logout paths").
- Model outage and propagation into tools: the "Elevated errors on Claude Opus 4.6" incidents show that failures can also be model-specific while still affecting several products downstream — the web app, console, coding assistant, and API.
- Load spike as a plausible trigger: Bloomberg quoted "unprecedented demand" and a temporary shutdown of consumer-facing surfaces. In France, 01net reported roughly a 60% increase in free signups and a doubling of paid subscriptions, tying that influx to a global outage — figures that should be treated as press-reported signals rather than official status metrics.
The structural reading is clear: any organization that places Claude in a critical path — customer support, code generation, back office, lead qualification — takes on supplier risk comparable to any critical SaaS dependency, with one particularity: AI is often used in workflows where users expect real-time responsiveness. The March 2–3 incidents show that a "single provider, single surface" design creates immediate operational breakage risk, even if the company is not yet using AI in a directly revenue-generating function.
Factual timeline
The elements below are built by prioritizing Anthropic’s status pages, statements reported by major media, and then Reddit and X community signals used primarily as a temperature check rather than as technical proof.
- 12026-03-02, 11:49 UTC — Start of incident "Elevated errors on claude.ai, console, and claude code" (Investigating).
- 22026-03-02, 12:21 UTC — Update: API stated to be operational, issue linked to login/logout paths.
- 32026-03-02, 13:37 UTC — Update: some API methods are not functioning.
- 42026-03-02, 15:47 UTC — Incident marked resolved.
- 52026-03-02, 16:50 UTC — Incident "Elevated errors on Claude Opus 4.6" (Investigating, then Resolved at 17:55).
- 62026-03-03, 03:15 UTC — New incident "Elevated errors in claude.ai, cowork, platform, claude code."
- 72026-03-03, 06:59 UTC — Incident "Elevated errors on Claude Opus 4.6" (Investigating).
- 82026-03-03, 08:39 UTC — claude.ai / platform / Claude Code surfaces: fix implemented (Monitoring).
- 92026-03-03, 10:27 UTC — Opus 4.6: fix implemented (Monitoring).
Community signals: threads such as "Claude is down" or the automated "Claude Status Update" posts on r/ClaudeAI quickly relayed links to status.claude.com and aggregated user reports — login failures, rate limit errors, slowdowns, or denied access. On X, several technical comments described the issue more as a "login/UI under load" event than an "inference/model failure," which broadly aligns with the March 2 updates.
Quantitative impact and estimates
Hard public measurements available
- March 2, 2026: 11:49 → 15:47 UTC, about 238 minutes of multi-surface incident time.
- March 2, 2026: 16:50 → 17:55 UTC, about 65 minutes of Opus 4.6 incident time impacting claude.ai, platform, API, and Claude Code.
- March 3, 2026: 03:15 → 09:36 UTC, about 381 minutes until Monitoring for the multi-surface incident, without Resolved at that timestamp.
- March 3, 2026: 06:59 → 10:27 UTC, about 208 minutes until Monitoring for the Opus 4.6 incident, without Resolved at that timestamp.
Report volume (proxy): Bloomberg mentioned nearly 2,000 reports at peak on Downdetector. Other media referred to hundreds of reports. It is important to remember that this is a user-report aggregation platform, not a direct measurement of the actual number of affected users.
StatisticsThe March 2–3, 2026 Claude incidents in numbers · shareable block
238 min
March 2 multi-surface incident
65 min
March 2 Opus 4.6 incident
381 min
March 3 degradation until monitoring
≈ 2,000
Peak Downdetector reports
Structured estimates (hypotheses explicitly labeled)
Because Atlassian Statuspage rarely publishes exact provider-side error rates, and Anthropic had not published a detailed public postmortem for this sequence at the time of consultation, it is useful to reason with operational hypotheses.
- Hypothesis A — auth/UI error profile: if the outage primarily hits login/logout, the end-user fail rate across the path login → history access → chat can become very high during peak periods, for example above 30% to 70%, while already-authenticated API requests may remain partially functional.
- Hypothesis B — overload error profile: Anthropic’s documentation defines a 529 overloaded_error and mentions periods of high traffic as a cause. In a demand spike, the expected failure mode is therefore likely a mix of 5xx errors, overload conditions, and timeouts — several articles also reported 500/504 errors and white screens.
Business impact estimate
Without internal client metrics, the most robust method is to reason at a microeconomic level by use case. For internal productivity (dev/support teams): Impact ≈ (dependent headcount) × (duration) × (loaded hourly cost) × (dependency factor). Illustrative example: 40 people × 4 h × $80/h × 0.6 = $7,680 in opportunity cost.
For a SaaS product using Claude in the customer path, even if the AI is "just an assistant," unavailability can lead to lower conversion or higher churn. It is essential to distinguish critical functions — response generation, triage, agent actions — from convenience features such as summarization or rewriting.
Plausible distribution of causes
This typology is based on public signals visible across AI incidents in late February and early March 2026 — a portfolio-level risk view inspired by public signals from Claude, OpenAI, and Google.
ChartPlausible typology of AI incident causes · shareable block
Distribution of cited causes
% of cited causes
50%
25%
20%
5%
Configuration change / feature flag
Authentication / session / UI
Capacity / overload / scaling
Other / undetermined
Benchmark comparison with ChatGPT and Gemini outages
The key point is not simply to count outages, but to compare their duration, blast radius, the quality of the published write-ups, and the prevention mechanisms highlighted.
TableBenchmark of recent AI incidents · shareable block
| Incident (summary) | Window and key lesson | |
|---|---|---|
| OpenAI | "Elevated error rates for ChatGPT and Platform users" | Incident triggered by a configuration change introducing an unexpected type; retries amplified the load; circuit breakers are listed among the prevention measures. |
| Google Cloud | "Vertex Gemini API customers experienced increased error rates…" | Incident linked to a configuration change, fixed through rollback, with downstream impact on other products. |
| Anthropic | "Elevated errors…" on claude.ai / platform / Claude Code, followed by Opus 4.6 | Status updates pointed to login/logout plus elevated errors; a sequence of multiple incidents across March 2 and 3; no detailed public postmortem available at the time of the consulted updates. |
Aggregate availability: status dashboards publish overall uptime figures. OpenAI’s status page, for example, showed 99.76% API uptime and 98.90% ChatGPT uptime over the December 2025 to March 2026 period, while explicitly noting that individual experience varies by tier and feature. On Google Workspace, Gemini’s status history shows incidents that can last for extended periods, including cases where conversation history was no longer visible — reminding us that an outage can be functional rather than a full hard-down event.
Risk matrix and recommended mitigations
Risk matrix
TableRisk matrix — AI in production · shareable block
| Probability / Impact | Why it matters | |
|---|---|---|
| AI provider outage (hard down) | M / H | Interrupts critical workflows and creates exposure against client-facing SLAs. |
| Degradation (latency / errors) | H / M-H | Degraded user experience, increased support load, lower conversion. |
| Authentication / session outage | M / H | Creates the perception that "everything is down" even when inference remains partially available. |
| Configuration / compatibility change | M / H | OpenAI and Google postmortems show the feature-gate + retry amplification effect. |
| Single-API dependency (lock-in) | H / M-H | Makes crisis switchover difficult and raises future migration costs. |
| Compliance / sovereignty / data residency | M / H | Especially sensitive in finance, healthcare, and the public sector. |
Mitigation options
TableMitigation options against AI outage risk · shareable block
| Benefits | Limits | |
|---|---|---|
| Standard retries + backoff (low cost) | Simple and quick to implement. | Can worsen an outage by creating a retry storm. |
| Circuit breaker / fail-fast (low to medium cost) | Stops amplification and protects dependencies. | Requires properly tuned SLOs and thresholds. |
| Cache + "read-only summary" mode (medium cost) | Maintains a minimum level of user value. | Does not replace a full interactive agent. |
| Multi-model routing, Claude ↔ alternatives (medium to high cost) | Reduces supplier risk and improves continuity. | Requires cost/quality governance and equivalence testing. |
| Multi-region / multi-endpoint cloud design (medium cost) | Reduces localized infrastructure risk. | Does not cover global logical failures. |
| Contracts & governance, SLAs / postmortems (low to medium cost) | Clarifies responsibilities, expectations, and service credits. | Does not technically solve an outage. |
Target architecture: multi-model failover routing
The goal is to avoid ever blocking the end user and to accept controlled degradation in quality or functionality rather than a complete stop.
- 1Web / app / agent client — the user sends a request.
- 2AI Gateway / orchestrator — routes to the primary provider with continuous health checks and SLOs (errors, latency, timeouts).
- 3Primary provider (Claude) → on degradation, fails over to the secondary provider (ChatGPT / API), then tertiary (Gemini / API).
- 4Degraded mode — if all providers fail: cache, response templates, queueing, rather than a complete stop.
- 5Post-processing — security, PII, policy applied before the final response.
- 6Logs & traces — observability and cost tracking at every step, through to the user response.
Associated minimum governance
InfographicThree governance guardrails · shareable block
01
Failover policy
Define when to switch, to which endpoints, and under which guardrails — for example restricting certain functions while in fallback mode.
02
Incident playbook
Specify who decides, what messages are sent to clients, and how to return to the primary provider.
03
Change management
Apply the same rigor as the providers themselves: review, canary deployment, rollback strategy, blast-radius control.
Frequently asked questions
Why is an AI assistant outage like Claude a business risk?+
Because the risk is not only "the AI gets things wrong," but also "the AI becomes unavailable." An organization that places an AI assistant in a critical path — support, code, back office — inherits supplier risk comparable to any critical SaaS dependency, with the added expectation of real-time responsiveness.
What are the most common causes of AI outages?+
Based on the typology observed across the Claude, OpenAI, and Google incidents from late February–early March 2026: roughly 50% configuration change / feature flag, 25% authentication / session / UI, 20% capacity / overload, and 5% other undetermined causes.
How can I reduce single-vendor AI risk?+
By implementing multi-model routing (primary, secondary, tertiary provider), a fail-fast circuit breaker, and a degraded mode (cache, response templates) instead of a complete stop when the primary vendor is unavailable.
What is multi-model routing and how does it work?+
It is an architecture where an AI Gateway / orchestrator continuously monitors the health of the primary provider (errors, latency, timeouts) and automatically fails over to a secondary then tertiary provider on degradation, before post-processing and returning a response to the user.
What does a multi-model resilience strategy cost?+
It varies by option: retries/backoff and governance contracts are low-cost, circuit breakers and caching are low-to-medium cost, while multi-model routing and multi-region design are a medium-to-high investment but reduce supplier risk the most.
Is a circuit breaker enough to avoid a complete outage?+
No. A circuit breaker stops amplification and protects dependencies, but it requires properly tuned SLOs and thresholds — it does not replace multi-model routing or a degraded mode that maintains a minimum level of value for the user.
How do I estimate the cost of an AI outage for my business?+
Reason by use case: for internal productivity, Impact ≈ (dependent headcount) × (duration) × (loaded hourly cost) × (dependency factor) — for example 40 people × 4 h × $80/h × 0.6 = $7,680 in opportunity cost for a multi-hour outage.
Does your business depend on a single AI vendor?
We assess your exposure to AI vendor risk — architecture, single points of failure, SLOs — and propose a prioritized multi-model resilience plan.
D
Written by
DAILLAC
