A 17 de agosto de 2026 o GitHub esteve em baixo durante sete horas e quarenta e sete minutos. Foram com ele a autenticação, o Actions, a API, os pull requests, as issues e o Copilot, e um grande número de equipas passou parte dessa tarde a perceber se a build que se tinha partido era a delas.
Essa pergunta - somos nós ou são eles - é daquelas que convém saber responder em dois minutos e não em duas horas, e as provas que lhe respondem desaparecem quando o incidente termina.
As provas, pela ordem em que ajudam
Que host está a falhar. Abra o separador Rede e veja para onde vão os pedidos que falham. Um 500 do seu próprio domínio é seu. Um 503 de uma API que não é sua não é, por muito que pareça que a funcionalidade partida é a sua. Parece óbvio e é o passo que se salta, porque o sintoma aparece na sua interface e a interface é o que se está a olhar.
O que diz o código de estado. Um 401 ou um 403 durante o incidente de autenticação de outra pessoa não é um erro de permissões no seu código, e é o que mais vezes é arquivado como tal. Um 429 é um limite de pedidos e pode ser consequência das suas próprias retentativas. Um timeout sem resposta nenhuma aponta para fora mais vezes do que para dentro.
Se coincide com o seu deploy. A primeira pergunta em qualquer canal de incidentes é o que mudou. Se a sua última release foi três horas antes de os sintomas começarem, vale a pena dizê-lo na primeira mensagem e não na quinta.
O que diz a página de estado deles, consultada em segundo lugar e não em primeiro. As páginas de estado são atualizadas por pessoas ocupadas a apagar o fogo, e vão uns minutos atrás da falha. O seu próprio separador Rede sabe antes da página de estado deles.
A armadilha: as suas retentativas podem piorar a situação
A parte do relato do GitHub que vale a pena ler duas vezes é o que aconteceu durante a recuperação. O post mortem deles diz:
Os erros nesses serviços desencadearam um ciclo de retentativas do lado do cliente que aumentou o tráfego durante a recuperação. Tivemos de mitigar esse comportamento antes de conseguirmos restabelecer o tráfego em segurança.
Ou seja, os clientes que mais se esforçavam por passar faziam parte do que mantinha a porta fechada. A lista de medidas do GitHub nomeia a correção em termos gerais - “limites de retentativas coerentes, orçamentos de retentativas e timeouts variáveis nas interações entre serviços, para evitar tempestades de retentativas e carga em cascata” - e essa é uma frase que vale a pena pôr ao lado do seu próprio código.
Lógica de retentativa escrita para um pedido falhado isolado comporta-se de outra maneira quando todos os pedidos falham. Sem orçamento, sem backoff e sem jitter, cem instâncias a repetir todas com o mesmo calendário tornam-se um teste de carga sincronizado apontado a um serviço que já está a sofrer.
Vale também a pena saber que nenhum dos dois incidentes do GitHub em agosto veio de uma alteração de código ou de configuração. Ambos foram falhas de capacidade. O instinto de procurar o deploy que o causou costuma acertar e aqui estava errado.
Capture-o enquanto está partido
Uma falha é a única categoria de defeito que se repara sozinha, e as provas vão com ela. Duas horas depois, o pedido que devolvia um 503 devolve um 200, e o ticket diz “falha intermitente, não reproduzível” para o resto da vida.
O que quer, recolhido durante o incidente: os pedidos falhados com os seus códigos de estado e tempos, a saída da consola, e a hora a que cada um aconteceu.
Session Replay
Extensão gratuita do Chrome. Um clique na página que se está a portar mal captura a captura de ecrã, a consola e o registo de rede, e devolve-lhe um link para colar no ticket.
O registo de rede inclui um ficheiro HAR, que é o artefacto que o suporte do outro lado lhe vai pedir de qualquer maneira. Limpe-o antes de o enviar para a frente: um HAR guardado com conteúdos leva cookies de sessão e cabeçalhos de autorização, e é a única coisa deste fluxo de trabalho que já provocou uma fuga de dados noutra empresa.
Escrevê-lo de forma a não ser mal arquivado
Um relatório de incidente e um relatório de erro são documentos diferentes, e confundi-los custa uma manhã a um programador.
Se a falha é de outra pessoa, diga-o no título, e diga o que significa para si: que funcionalidade está afetada, se há uma solução de recurso e o que está à espera. “Checkout a falhar - o fornecedor de pagamentos devolve 503 desde as 14:10, sem solução de recurso, a página de estado deles reconhece-o” é um relatório completo. Ninguém precisa de o reproduzir, e ninguém deve tentar.
Se pode ser seu, é um relatório de erro vulgar e quer as coisas do costume: o que esperava, o que aconteceu, o ambiente e as provas. O nosso guia para escrever um tem a forma, e os dez erros mais comuns cobrem o que costuma faltar.
E se realmente ainda não sabe, escreva isso. “Não é claro se é nosso - os pedidos que falham vão para um host externo, mas a nossa release saiu às 13:30” é mais útil do que um palpite confiante numa direção ou noutra.
Depois
Duas perguntas que vale a pena fazer quando o incidente acabou, enquanto as pessoas ainda se lembram.
Quanto tempo demorámos a saber que não éramos nós? Se a resposta for uma hora, a correção está normalmente na visibilidade e não na resiliência: um sítio onde olhar que mostre que hosts estão a falhar.
As nossas retentativas ajudaram ou prejudicaram? O GitHub teve de mitigar o comportamento dos clientes antes de poder restabelecer o tráfego. Os seus clientes são o comportamento de cliente de outra pessoa.
Fontes: o relato que o GitHub faz do incidente está em The August 17 outage, and the work ahead, e é invulgarmente concreto sobre o que correu mal. Publicado em abono deles, e citado aqui porque um post mortem que nomeia as tempestades de retentativas é mais útil do que qualquer conselho sobre elas.