È un tuo bug o un loro disservizio? Distinguerlo mentre sta succedendo

Il 17 agosto 2026 GitHub è rimasto giù per sette ore e quarantasette minuti. Sono caduti con lui l’autenticazione, Actions, l’API, le pull request, le issue e Copilot, e moltissimi team hanno passato una parte di quel pomeriggio a capire se fosse la loro build a essersi rotta.

Quella domanda - siamo noi o sono loro - è una a cui conviene saper rispondere in due minuti anziché in due ore, e le prove che le rispondono spariscono quando l’incidente finisce.

Le prove, nell’ordine in cui servono

Quale host sta fallendo. Apri la scheda Rete e guarda dove vanno le richieste che falliscono. Un 500 dal tuo dominio è tuo. Un 503 da un’API che non gestisci tu non lo è, per quanto sembri che la funzionalità rotta sia la tua. Sembra ovvio ed è il passaggio che si salta, perché il sintomo compare nella tua interfaccia e l’interfaccia è quello che si sta guardando.

Cosa dice il codice di stato. Un 401 o un 403 durante l’incidente di autenticazione di qualcun altro non è un bug di permessi nel tuo codice, ed è quello che più spesso viene archiviato come tale. Un 429 è un limite di frequenza e può essere una conseguenza dei tuoi stessi retry. Un timeout senza alcuna risposta punta fuori più spesso che dentro.

Se coincide con il tuo deploy. La prima domanda in qualsiasi canale di incidente è cosa è cambiato. Se la tua ultima release è di tre ore prima dell’inizio dei sintomi, vale la pena dirlo nel primo messaggio e non nel quinto.

Cosa dice la loro pagina di stato, guardata per seconda e non per prima. Le pagine di stato le aggiornano persone impegnate a spegnere l’incendio, e sono indietro di qualche minuto rispetto al guasto. La tua scheda Rete lo sa prima della loro pagina di stato.

La trappola: i tuoi retry possono peggiorare le cose

La parte del racconto di GitHub che vale la pena leggere due volte è quello che è successo durante il ripristino. Il loro post mortem dice:

Gli errori in quei servizi hanno innescato un ciclo di retry lato client che ha aumentato il traffico durante il ripristino. Abbiamo dovuto mitigare quel comportamento prima di poter riaprire il traffico in sicurezza.

Quindi i client che si sforzavano di più di passare erano parte di ciò che teneva la porta chiusa. L’elenco dei rimedi di GitHub nomina la correzione in termini generali - “limiti di retry coerenti, budget di retry e timeout variabili nelle interazioni tra servizi, per evitare tempeste di retry e carico a cascata” - ed è una frase da tenere accanto al proprio codice.

Una logica di retry scritta per una singola richiesta fallita si comporta diversamente quando falliscono tutte le richieste. Senza un budget, senza backoff e senza jitter, cento istanze che riprovano tutte con lo stesso calendario diventano un test di carico sincronizzato puntato su un servizio che è già in difficoltà.

Vale anche la pena sapere che nessuno dei due incidenti di agosto di GitHub è nato da una modifica al codice o alla configurazione. Entrambi erano problemi di capacità. L’istinto di cercare il deploy che l’ha causato di solito ci prende e qui sbagliava.

Catturalo mentre è rotto

Un disservizio è l’unica categoria di difetto che si ripara da sola, e le prove se ne vanno con lui. Due ore dopo la richiesta che restituiva un 503 restituisce un 200, e il ticket dice “fallimento intermittente, non riproducibile” per il resto della sua vita.

Quello che ti serve, preso durante l’incidente: le richieste fallite con i loro codici di stato e i loro tempi, l’output della console e l’ora in cui ciascuna è avvenuta.

Il registro di rete comprende un file HAR, che è l’artefatto che il supporto dall’altra parte ti chiederà comunque. Ripuliscilo prima di mandarlo avanti: un HAR salvato con i contenuti porta con sé cookie di sessione e header di autorizzazione, ed è l’unica cosa di questo flusso che ha già causato una fuga di dati in un’altra azienda.

Scriverlo in modo che non finisca nel posto sbagliato

Un rapporto di incidente e una segnalazione di bug sono due documenti diversi, e confonderli fa perdere una mattinata a uno sviluppatore.

Se il guasto è di qualcun altro, dillo nel titolo, e di’ cosa significa per voi: quale funzionalità è colpita, se c’è un aggiramento e cosa state aspettando. “Checkout non funziona - il fornitore di pagamenti a monte restituisce 503 dalle 14:10, nessun aggiramento, la loro pagina di stato lo conferma” è una segnalazione completa. Nessuno ha bisogno di riprodurla, e nessuno dovrebbe provarci.

Se potrebbe essere tuo, è una normale segnalazione di bug e vuole le cose di sempre: cosa ti aspettavi, cosa è successo, l’ambiente e le prove. La nostra guida per scriverne una ne dà la forma, e i dieci errori più comuni coprono quello che di solito manca.

E se davvero non lo sai ancora, scrivi quello. “Non è chiaro se sia nostro - le richieste che falliscono vanno a un host esterno, ma la nostra release è uscita alle 13:30” è più utile di un’ipotesi sicura di sé in una direzione o nell’altra.

Dopo

Due domande che vale la pena porsi a incidente chiuso, finché le persone se lo ricordano ancora.

Quanto ci abbiamo messo a sapere che non eravamo noi? Se la risposta è un’ora, la soluzione di solito sta nella visibilità più che nella resilienza: un posto dove guardare che mostri quali host stanno fallendo.

I nostri retry hanno aiutato o peggiorato? GitHub ha dovuto mitigare il comportamento dei client prima di poter riaprire il traffico. I vostri client sono il comportamento client di qualcun altro.

---

Fonti: il racconto che GitHub fa dell’incidente è in The August 17 outage, and the work ahead, ed è insolitamente preciso su cosa sia andato storto. Pubblicato a loro merito, e citato qui perché un post mortem che nomina le tempeste di retry è più utile di qualsiasi consiglio su di esse.