Resumo
- O incidente classificado como major durou de 07:53:59.358 a 09:39:19.558 UTC, ou 1 hora 45 minutos 20,200 segundos.
- GitHub listou Webhooks, Actions, Issues e Pull Requests como componentes afetados.
- Actions podia demorar para iniciar trabalhos e a busca de Issues podia exibir resultados desatualizados.
- Às 09:22:21 UTC, GitHub disse ter identificado a origem da latência e aplicado uma correção, enquanto filas eram processadas.
- O provedor prometeu uma análise detalhada de causa raiz, mas não publicou o mecanismo nem a escala de usuários.
Um Webhook conecta um evento no GitHub a outra ação: atualizar um sistema, acionar uma automação, registrar uma mudança. Se a entrega sofre latência, o destinatário não sabe imediatamente se o evento ainda virá ou se deve buscá-lo por outro caminho.
O status do GitHub não informa quantos callbacks atrasaram nem afirma que foram perdidos. Registra Webhooks como degradado e, mais tarde, diz que serviços restantes melhoravam enquanto filas de processamento eram esvaziadas.
Essa condição já impõe um custo. O cliente precisa decidir se espera, consulta a origem ou executa novamente alguma ação. Uma nova tentativa pode ser necessária, mas também pode produzir duplicidade caso o evento original seja entregue depois.
Não há evidência publicada de duplicidade neste incidente. Há necessidade de projetar e operar o sistema conectado para esse risco.
O estado atravessou quatro superfícies
O incidente começou às 07:53:59.358 UTC com relatos sobre Actions, Issues e Webhooks. Pull Requests entrou na lista às 08:25:16.
GitHub explicou às 08:34:23 que trabalhos do Actions demoravam mais para começar e que a pesquisa de Issues podia servir resultados antigos. Assim, automação, informação, eventos e revisão humana podiam refletir momentos diferentes.
Issues foi mitigado às 09:18:37 e Actions às 09:19:49. Às 09:22:21, o provedor informou que havia identificado a fonte e aplicado uma correção. Pull Requests foi mitigado às 09:27:35, Webhooks voltou ao normal às 09:35:17 e o incidente foi encerrado às 09:39:19.558.
A sequência demonstra que correção e esvaziamento das filas são etapas distintas. Sistemas dependentes podem continuar reconciliando eventos depois que a plataforma informa estabilidade.
Não há causa raiz pública ainda
GitHub disse ter identificado a fonte de latência, sem divulgar componente, implantação, dependência ou falha de infraestrutura. Na resolução, prometeu compartilhar uma análise detalhada assim que disponível.
O envolvimento de quatro serviços sugere propagação, mas não identifica o mecanismo comum. Não é possível atribuí-lo a banco de dados, mensageria ou nuvem externa com os dados atuais.
Também não há número de organizações, jobs, eventos ou repositórios atingidos, nem estimativa financeira. A duração de 1 hora 45 minutos 20 segundos é a janela do incidente, não um valor de perda multiplicável.
O episódio é diferente da demora em runners hospedados em 22 de julho. Os horários, produtos e sintomas divulgados mudaram; a proximidade não prova uma causa única.
A análise prometida deverá explicar o gatilho, a propagação e o tratamento seguro de filas. Para clientes de Webhooks, o teste adicional é saber como o provedor garante ordem, entrega e observabilidade durante a recuperação.
Até lá, a conclusão econômica é a dependência externa: uma fila dentro da plataforma transfere reconciliação, verificação e tempo de engenharia para cada sistema que esperava o evento.