Claude non funziona oggi? Come verificarlo in 30 secondi e cosa fare subito

Ultimo aggiornamento: 17 agosto 2026. All’ultimo controllo la dashboard ufficiale di Anthropic riportava All Systems Operational: nessun incidente aperto su chat, API e Claude Code. L’ultimo disservizio chiuso risale a poche ore prima — un’interruzione classificata critical su tutti i servizi, aperta il 16 agosto alle 21:58 UTC e risolta alle 22:34, trentasei minuti in tutto. Il dato non è letto a occhio dalla pagina, ma preso dagli endpoint pubblici status.claude.com/api/v2/summary.json e /api/v2/incidents.json, che restituiscono stato dei componenti e storico in formato leggibile da una macchina. Questa pagina viene ripassata periodicamente, ma l’unica fonte che vale è quella in tempo reale: qui sotto trovi come leggerla in trenta secondi, quanto durano davvero i disservizi, cosa significano i codici di errore che ti compaiono davanti, e perché a volte il servizio è formalmente su ma le risposte peggiorano.

In questo articolo scoprirai:

• Verifica in 30 secondi se il servizio è davvero down
• Le quattro cause ricorrenti
• Quanto dura di solito un down di Claude, numeri alla mano
• Il dizionario degli errori: cosa ti sta dicendo davvero il codice
• Quando il modello non cade, ma peggiora: il caso Sonnet 4 e Haiku 3.5
• Sembra un blocco, invece è il tetto del piano

Verifica in 30 secondi se il servizio è davvero down

1. Apri la dashboard ufficiale → status.claude.com (dieci secondi). Non guardare solo il semaforo in cima: i componenti sono monitorati separatamente. Al 17 agosto 2026 ne risultano sei — claude.ai, Claude Console (platform.claude.com), Claude API (api.anthropic.com), Claude Code, Claude Cowork e Claude for Government. Se il componente che usi tu è verde, il problema non è generale.
2. Controlla le segnalazioni degli altri utenti su Downdetector (dieci secondi). Un picco verticale nell’ultima ora significa disservizio diffuso; una linea piatta significa che il problema è probabilmente solo tuo. È un indizio, non una prova: Downdetector misura le lamentele, non l’infrastruttura.
3. Isola il tuo lato (dieci secondi): finestra in incognito, un’altra rete (anche l’hotspot del telefono), un altro modello dal selettore. Se in incognito funziona, non è un down: è sessione, cache o un’estensione del browser.

Un’avvertenza che vale la pena tenere a mente, perché sembra un paradosso e invece è successo davvero: anche la status page può essere irraggiungibile. Il 14 agosto 2026 la cronologia ufficiale registra un incidente intitolato «Issues reaching status.claude.com», aperto alle 07:58 UTC e chiuso alle 10:53 — quasi tre ore in cui lo strumento che dovrebbe dirti se il servizio è giù era lui stesso il problema. Se la pagina non carica, non dedurne che sia caduto tutto: passa al secondo e al terzo controllo.

Se tutti e tre i controlli danno verde e l’errore resta, nella maggior parte dei casi non è un guasto ma i limiti di utilizzo che sembrano un down.

Le quattro cause ricorrenti

Quando Claude non funziona per un guasto lato Anthropic

• Incidente lato Anthropic. È il caso che finisce sulla status page, di solito entro pochi minuti dall’inizio. La pagina uptime a 90 giorni tiene lo storico componente per componente: è lì che si misura quanto spesso succede davvero, invece di andare a impressione. Il valore scorre nel tempo, quindi alla tua lettura sarà diverso da quello di oggi.
• Degrado di un singolo modello. Non cade tutta la piattaforma: capita che un modello registri errori elevati, o risposte peggiori, mentre gli altri rispondono normalmente. È la casistica più frequente nella cronologia recente, dove gli incidenti sono intitolati al singolo modello coinvolto — nell’agosto 2026 ricorrono Sonnet 5, Opus 5, Fable 5 e Mythos 5. Rimedio immediato: cambia modello dal selettore — se non sai quali alternative hai e in cosa si differenziano, il quadro è nella guida completa a Claude AI. È il caso più insidioso, e più avanti vediamo perché.

Quando Claude non funziona per sovraccarico o per la rete

• Sovraccarico temporaneo. Errori di tipo overloaded, risposte lente o troncate nelle fasce di punta. Non è un guasto: è capacità. La documentazione ufficiale classifica questo caso come 529 overloaded_error e precisa che si verifica «quando l’API sperimenta traffico elevato su tutti gli utenti»: non dipende dal tuo account.
• Guasto a monte, fuori da Anthropic. Rete, DNS o infrastruttura di distribuzione: il servizio è in piedi ma tu non lo raggiungi, e la status page resta verde. È già successo su scala globale, come nel post-mortem Cloudflare del 18 novembre 2025 — l’abbiamo raccontato in quando l’AI si ferma: il caso Cloudflare.

Quanto dura di solito un down di Claude, numeri alla mano

È la domanda vera di chi arriva qui: non «è giù?», ma «quando torna?». La cronologia pubblica permette di rispondere senza tirare a indovinare. Prendendo i dodici incidenti risolti più recenti, che coprono appena tredici giorni (dal 4 al 16 agosto 2026), il quadro è questo: nove su dodici sono rientrati in meno di due ore, e la mediana sta sotto l’ora. Gli orari della status page sono in UTC, due ore indietro rispetto all’ora italiana d’estate.

Il dato controintuitivo è quale sia il tipo di incidente che dura di più. Non è l’interruzione grave. Il blocco critico del 16 agosto, quello che ha toccato tutti e cinque i componenti principali, è durato 36 minuti; gli errori elevati su più modelli del 13 agosto, classificati major, 95 minuti; quelli del 4 agosto, 25 e 39 minuti. I due incidenti più lunghi del periodo sono invece entrambi etichettati «degraded performance», cioè servizio in piedi ma peggiore: quattro ore e un quarto il 12 agosto su più modelli, e poco più di sette ore il 5 agosto.

La regola pratica che se ne ricava è ruvida ma affidabile: se è caduto tutto, aspetta — statisticamente rientra entro un’ora o due. Se invece il servizio risponde e va solo male, mettiti l’animo in pace: quella è la categoria che storicamente resta aperta per mezza giornata di lavoro, ed è anche quella che non ti accorgi di avere. Un avvertimento onesto sul metodo: dodici incidenti sono un campione piccolo e tredici giorni sono una finestra corta, quindi questi numeri descrivono un periodo, non promettono il prossimo.

Claude Code non funziona ma la chat sì: perché succede

Capita spesso, e non è un tuo errore di configurazione: i componenti cadono separatamente. Nella stessa finestra di agosto ci sono incidenti che hanno colpito Claude API, Claude Code e Claude Cowork lasciando fuori claude.ai — il 14 agosto, per 88 minuti — e un altro, sempre il 14 agosto, limitato al solo Claude Cowork per un quarto d’ora. La chat nel browser continuava a rispondere mentre il terminale no.

Il che significa due cose. La prima: quando controlli la status page, guarda la riga del tuo componente, non il titolo in cima. La seconda: se il terminale si comporta in modo strano ma la chat va, prima di dare la colpa a un down conviene escludere le cause locali — sessione scaduta, permessi, configurazione del progetto. Su cosa è normale che Claude Code chieda e cosa invece non dovresti concedergli, abbiamo messo giù una guida al primo giorno con Claude Code e ai permessi da non dare.

Il dizionario degli errori: cosa ti sta dicendo davvero il codice

Se usi l’API, il numero che compare nel messaggio di errore vale più di qualunque status page, perché è specifico della tua richiesta. La documentazione ufficiale sugli errori li elenca tutti; questi sono i quattro che si confondono più spesso fra loro.

I quattro codici di errore di Claude API che si confondono

• 429 rate_limit_error — sei tu ad aver superato un limite del tuo account, non l’infrastruttura ad essere rotta. Dettaglio poco noto e molto utile: la documentazione avverte che un’impennata improvvisa di consumo può far scattare un 429 per via dei limiti di accelerazione, e raccomanda di alzare il traffico gradualmente invece che tutto in una volta. Le soglie per fascia sono nella pagina sui rate limit.
• 529 overloaded_error — non è tuo, è di tutti. Si aspetta e si riprova, non si insiste.
• 500 api_error — errore interno ai sistemi di Anthropic. Qui la documentazione è esplicita: riprovare con backoff esponenziale e, se persiste, contattare il supporto allegando il request ID.
• 504 timeout_error — la richiesta è scaduta durante l’elaborazione. Non è un down: quasi sempre è una richiesta troppo lunga gestita nel modo sbagliato.

Gli errori di Claude che non vedi: request ID e streaming

Due cose che fanno risparmiare ore di diagnosi sbagliata. La prima: ogni risposta dell’API porta un header request-id (nella forma req_011CSHoEeqs5C35K2UUqR7Fy), ed è l’unico modo per far ritrovare al supporto la tua chiamata specifica invece di una descrizione a parole. Loggalo sempre, anche sulle chiamate riuscite. La seconda: in modalità streaming un errore può arrivare dopo che il server ha già risposto 200. Se il tuo codice considera «riuscita» qualunque richiesta che apre con 200, quei fallimenti diventano invisibili nei tuoi grafici — e tu credi a un down quando invece hai un bug di gestione degli eventi.

Quando il modello non cade, ma peggiora: il caso Sonnet 4 e Haiku 3.5

Esiste una categoria di problema che nessuno dei tre controlli iniziali intercetta, perché la status page resta verde: il modello risponde, ma risponde peggio. È la stessa categoria che, come abbiamo visto sopra, resta aperta per ore invece che per minuti. Non è un sospetto da forum. Anthropic lo ha documentato in prima persona nel post-mortem su tre problemi concomitanti del settembre 2025, ed è il testo da citare quando qualcuno liquida come suggestione la frase «mi sembra diventato più stupido». I modelli coinvolti sono ormai superati, ma il meccanismo che descrive no: è per questo che vale ancora la pena leggerlo.

I tre guasti documentati su Sonnet 4 e Haiku 3.5

• Errore di instradamento della finestra di contesto. Dal 5 agosto al 18 settembre 2025, su Sonnet 4: richieste brevi finivano su server configurati per il contesto da 1 milione di token. Colpiva lo 0,8% delle richieste all’inizio, con un picco al 16% il 31 agosto — e con incidenza molto diversa a seconda della piattaforma: 0,18% su Amazon Bedrock, sotto lo 0,0004% su Vertex AI.
• Corruzione dell’output. Dal 25 al 28 agosto 2025 su Opus 4.1 e Opus 4, e dal 25 agosto al 2 settembre su Sonnet 4: un’ottimizzazione delle prestazioni assegnava occasionalmente alta probabilità a token rari, con caratteri thailandesi o cinesi che spuntavano dentro risposte in inglese. Risolto con un rollback il 2 settembre.
• Miscompilazione XLA:TPU. Dal 25 agosto 2025, su Haiku 3.5 e, potenzialmente, su Sonnet 4 e Opus 3: un bug latente nel compilatore, innescato da una modifica al codice di selezione dei token.

La parte più istruttiva è l’ammissione sul perché ci sia voluto tanto: le valutazioni interne non catturarono la degradazione, e i controlli sulla privacy limitavano l’accesso degli ingegneri proprio alle interazioni problematiche. Tre bug diversi producevano sintomi incoerenti su piattaforme diverse, e questo rendeva difficile ricondurli ai singoli cambiamenti infrastrutturali.

Sonnet 4.5 non funziona: cosa dice davvero il post-mortem

Una precisazione onesta, visto che è una delle ricerche più frequenti: quel post-mortem non nomina Sonnet 4.5. Chi cerca «problemi Sonnet 4.5» quasi sempre sta incontrando un’altra cosa — sovraccarico, tetto del piano, o una regressione percepita ma mai documentata. Attribuire a un modello un incidente che riguardava un altro è il modo più rapido per diagnosticare male e cambiare la cosa sbagliata. Vale anche al contrario, oggi: gli incidenti di agosto 2026 riguardano la generazione successiva, e citare il post-mortem del 2025 per spiegarli è lo stesso errore rovesciato.

La conseguenza operativa è secca: se dipendi da un modello, la sua qualità va misurata da te, con un piccolo insieme di casi noti e risposte attese da rieseguire periodicamente. La status page ti dice se il servizio risponde, non se risponde bene.

Sembra un blocco, invece è il tetto del piano

È la confusione più frequente. I messaggi di limite raggiunto arrivano all’improvviso, spesso a metà lavoro, e assomigliano a un malfunzionamento — ma si azzerano allo scadere della finestra di utilizzo, non quando Anthropic risolve qualcosa. Il discrimine è semplice: status page verde + messaggio che parla di quota, limiti o attesa = non è un down. Sull’API lo stesso concetto ha un nome preciso, il 429 di cui sopra; nella chat e in Claude Code prende la forma della finestra di utilizzo che si esaurisce. Se ti succede spesso e stai valutando se il piano che hai è quello giusto, il conto vero — consumo reale su un mese di lavoro, non listino — l’abbiamo fatto in quanto costa Claude Code davvero al mese.

Cosa fa un’azienda quando il modello si ferma

Per chi usa la chat un’interruzione è un fastidio; per chi ha processi automatizzati sopra un modello è una fermata di produzione. E il conto si fa in anticipo: un ipotetico 99,4% su 90 giorni vale circa 13 ore di indisponibilità cumulata (su 2.160 ore, lo 0,6% mancante fa 12,96 ore). Non è un’anomalia da subire: è un budget di errore da mettere in conto in fase di progetto, esattamente nel senso descritto dal capitolo sugli SLO del Google SRE Workbook. Sostituisci quel 99,4% con il numero reale che leggi oggi sulla pagina uptime e hai il tuo budget.

Cinque difese per quando Claude AI non funziona

• Fallback multi-modello: il codice non chiama un modello, chiama un’astrazione che sa passare a un secondo provider quando il primo risponde male. «Risponde male» include le risposte fuori formato, non solo gli errori HTTP. Il secondo provider va scelto prima, non nel panico: il confronto sulle differenze reali è in Claude vs ChatGPT, quale conviene e per cosa.
• Retry con attesa crescente e timeout espliciti. Vale la pena sapere cosa fa già la libreria: gli SDK ufficiali ritentano da soli i fallimenti transitori con backoff esponenziale, due volte per impostazione predefinita, rispettando l’header retry-after quando presente. Il numero massimo di tentativi è configurabile. Se ci aggiungi il tuo retry senza saperlo, moltiplichi i tentativi e peggiori il sovraccarico che stai cercando di attraversare.
• Coda per il lavoro non interattivo: quello che non deve rispondere subito si accumula e riparte da solo al ripristino. Per i volumi grandi esiste la Batch API, che si interroga a polling e non dipende da una connessione ininterrotta — la documentazione la consiglia esplicitamente, insieme allo streaming, per le richieste che superano i dieci minuti.
• Priorità dichiarate: con i service tier si dichiara richiesta per richiesta quale traffico difendere quando la capacità stringe, invece di lasciare che sia il caso a decidere quale funzione cade per prima. Con un’avvertenza aggiornata: la documentazione segnala che gli impegni di capacità del Priority Tier non sono più acquistabili e restano validi solo per chi ne ha già uno a contratto — per tutti gli altri le leve vere sono coda e fallback.
• Degradazione dichiarata all’utente, invece di una schermata che gira a vuoto.

Sono scelte architetturali che si prendono prima del disservizio, non durante: è esattamente il terreno della continuità operativa con un partner.

Come farti avvisare, invece di ricaricare la pagina

Ricaricare la status page durante un disservizio è tempo perso. La stessa pagina permette di sottoscrivere gli aggiornamenti via email, SMS, Slack, Microsoft Teams e webhook: per un team, il webhook su un canale interno è la scelta che accorcia davvero i tempi, perché l’avviso arriva dove le persone stanno già guardando.

Chi vuole automatizzare ha una strada ancora più diretta, ed è quella che abbiamo usato per aprire questo articolo: l’endpoint /api/v2/summary.json della status page restituisce in JSON lo stato di ogni componente e l’elenco degli incidenti aperti, mentre /api/v2/incidents.json restituisce lo storico con orari di apertura e chiusura — è da lì che arrivano le durate citate sopra, e ricalcolarle sui tuoi componenti è questione di poche righe. Una decina di righe di script, e il tuo sistema sa distinguere da solo «il provider è giù» da «la mia integrazione è rotta» — che è poi l’unica domanda che conta nei primi due minuti di un’emergenza.

Fonti:

• Anthropic — Claude Status, dashboard ufficiale e cronologia incidenti
• Anthropic — Claude Status, uptime a 90 giorni per componente
• Anthropic — Claude API errors (429, 500, 504, 529, request ID)
• Anthropic — Rate limits
• Anthropic — Streaming messages ed error events
• Anthropic — Batch processing (Message Batches API)
• Anthropic — Service tiers
• Anthropic Engineering — A postmortem of three recent issues (17 settembre 2025)
• Cloudflare — Post-mortem dell’outage del 18 novembre 2025
• Google SRE Workbook — Implementing SLOs (error budget)