Claude (Anthropic) had vanochtend verhoogde error rates: dit gebeurde er en zo bouw je je app robuuster

Wie vanochtend met Claude werkte, kan het gemerkt hebben: meer mislukte requests, time-outs of onverwachte fouten. Volgens de officiële statuspagina van Claude was er op 22 mei 2026 een periode met elevated error rates die vooral Claude Opus 4.7 en Sonnet 4.6 raakte, en later ook Haiku 4.5. Ook diensten als claude.ai, de Claude API en de developer console stonden tijdelijk op ‘degraded’ of ‘partial outage’.

Wat gebeurde er precies? (korte tijdlijn)

De statusupdates laten twee momenten zien. Eerst was er een bredere verstoring waarbij meerdere modellen en onderdelen van het platform geraakt werden, die later in de ochtend als opgelost werd gemarkeerd. Daarna volgde nog een kortere, kleinere ‘blip’ specifiek rond Claude Opus 4.7 die snel werd verholpen.

Een handige check voor onafhankelijke monitoring is bijvoorbeeld StatusGator’s Anthropic-pagina, die dezelfde statuswisselingen verzamelt. In de praktijk is dat vooral nuttig voor teams die een alerting-keten hebben (Slack/PagerDuty) buiten de leverancier om.

Wat is de impact voor gebruikers en ontwikkelaars?

De impact verschilt per workflow. Voor eindgebruikers betekent ‘degraded performance’ meestal: trager, vaker een foutmelding en soms tijdelijke onbeschikbaarheid van bepaalde functies. Voor ontwikkelaars is het vooral pijnlijk als Claude een keten in je applicatie aanstuurt (supportbot, documentanalyse, agentic flows) en je geen fallback hebt.

Dit is ook een goed moment om je eigen afhankelijkheid te evalueren. AI-Feiten schreef eerder al over enterprise-adoptie en schaalbaarheid, zoals in KPMG rolt Claude uit voor 276.000 medewerkers en over developer tooling in Anthropic koopt Stainless. En als Claude steeds vaker in gespecialiseerde productie-workflows belandt (denk aan design/3D), wordt robuustheid nóg belangrijker—zie ook Claude richting Blender, Adobe en Autodesk.

Zo maak je Claude-integraties robuuster

• Implementeer retries met backoff bij 5xx/timeout (en log per model/endpoint).
• Fallback-model of leverancier: schakel tijdelijk naar een alternatief model als je use-case dat toelaat.
• Graceful degradation: laat je app ‘iets’ doen (bijv. samenvatting later, wachtrij) in plaats van hard falen.
• Monitoring op business-metrics (succesratio, latency, kosten) i.p.v. alleen ‘is de API up’.

Werk je met meerdere Claude-varianten (bijv. snel/goedkoop versus ‘topkwaliteit’), leg dan vast wanneer je overschakelt. In een eerdere AI-Feiten analyse over capaciteit en limieten (zie Anthropic verhoogt Claude-limieten na compute-deal) werd al duidelijk hoe belangrijk capaciteit en betrouwbaarheid zijn zodra AI ‘productie’ draait.

Wat betekent dit?

Het nieuws is niet dat er een storing was—dat gebeurt bij elke grote cloud—maar hoe afhankelijk AI-workflows inmiddels zijn geworden van één keten: model → API → console → agent tooling. Als jouw organisatie Claude gebruikt voor juridische of compliance-gevoelige processen (zoals besproken in Claude for Legal), dan is ‘uptime engineering’ geen bijzaak meer maar onderdeel van je AI-strategie.

De belangrijkste les: behandel een LLM net als elke andere kritieke dependency. Bouw je integratie alsof er af en toe een uur is met verhoogde foutkans—dan voelt zo’n ochtend niet als paniek, maar als een test die je systeem gewoon doorstaat.

Bronnen in context: statusupdates van Claude Status en onafhankelijke monitoring via StatusGator. Voor een snelle samenvatting die in de community rondgaat zie ook ModelsWar.