A falha global do GitHub e o que fica exposto quando a plataforma central cai
A 17 de agosto de 2026, por volta das 10h40 (hora de Brasília), o GitHub começou a falhar em todo o mundo.
Não foi uma degradação isolada de um serviço secundário: pull requests, issues, webhooks, autenticação (SAML, OIDC, SCIM, Team Sync), GitHub Actions e, pouco depois, o Copilot, ficaram todos afectados ao mesmo tempo.
Para uma plataforma usada por cerca de 180 milhões de programadores registados, isto não é uma notícia sobre o GitHub — é um lembrete sobre o que uma empresa está realmente a assumir quando constrói a sua operação em cima de um único fornecedor externo.
O que aconteceu, em factos
Segundo o relato da Exame, a falha começou por volta das 10h40 e afectou pull requests, issues, webhooks, GitHub Actions (a plataforma de automação usada para testes, builds e deployments) e serviços de autenticação como SAML, OIDC, SCIM e Team Sync.
O Copilot ficou com disponibilidade degradada a partir de cerca das 11h31. O download de repositórios apresentava uma taxa de erro de 50%, e o site e a API do GitHub uma taxa de erro de 20%.
O GitHub identificou o componente problemático por volta das 13h36 e aplicou uma correcção, sem divulgar a causa-raiz do incidente; os indícios apontavam para as camadas de autorização e routing, e não para fornecedores externos de IA.
A Microsoft confirmou a interrupção global, e o GitHub reportou "sinais consistentes de recuperação", ainda com taxas de erro elevadas nas horas seguintes.
Não foi um incidente isolado
O artigo da Exame enquadra esta falha como a mais grave de uma série recente de incidentes que já tinham afectado Actions, Pages e Copilot.
Isso importa: um incidente único é má sorte; uma série de incidentes é um padrão, e um padrão muda a forma como uma equipa deve planear em torno dele.
Se a automação de deployment, a autenticação de equipa e o assistente de código de uma empresa dependem todos da mesma plataforma, uma falha nessa plataforma não é um inconveniente — é uma paragem completa da capacidade de entregar software nesse dia.
Porque é que isto afecta empresas que nem usam GitHub Actions para produção
Mesmo equipas que não usam Actions para deployment sentem o impacto: se a autenticação (SAML/OIDC) fica em baixo, ninguém consegue aceder ao código; se as pull requests ficam em baixo, o trabalho de revisão pára; se o Copilot fica indisponível, uma parte do fluxo diário de quem escreve código também pára.
O GitHub deixou de ser "onde o código vive" para se tornar infra-estrutura crítica de entrega de software e, cada vez mais, de assistência por IA — e infra-estrutura crítica exige o mesmo nível de plano de contingência que uma empresa aplicaria à sua própria base de dados ou ao seu próprio servidor de produção.
O risco não é usar o GitHub — é não ter plano para quando ele falhar
A resposta correcta a este tipo de incidente não é abandonar uma plataforma amplamente usada e comprovada — é assumir, por hipótese de trabalho, que ela vai falhar outra vez, e desenhar a operação para sobreviver a isso.
Na prática isso significa: automação crítica que não depende inteiramente do runner de CI de um único fornecedor; segredos e credenciais geridos de forma a que uma falha de autenticação externa não bloqueie sistemas internos; e uma distinção clara entre o que é "conveniente centralizar num fornecedor" e o que é "crítico ao ponto de precisar de redundância".
O paralelo com o que esta sessão de manutenção mostrou na PontoTi
Esta mesma noite de operação da PontoTi ilustrou o princípio na prática, embora numa escala muito menor: quando um único processo (um hook com fuga de memória) consumiu quase toda a RAM disponível na VPS, os serviços de publicação, monitorização e alertas continuaram a funcionar porque estão desenhados como unidades systemd independentes, cada uma com o seu próprio ciclo de vida, e não como um único processo monolítico do qual tudo depende.
Um lock parado bloqueou só o healthcheck, não os restantes jobs; um script com erro de sintaxe falhou isoladamente, sem arrastar os outros alertas consigo.
É o mesmo raciocínio de resiliência que uma falha do tamanho da do GitHub torna visível à escala global: isolar falhas em vez de deixar um único ponto arrastar tudo.
O que vale a pena rever depois de ler sobre isto
Três perguntas práticas para qualquer equipa técnica depois de um incidente destes: o que pára completamente de funcionar, hoje, se o GitHub (ou o equivalente que a empresa usa) ficar em baixo quatro horas?
Existe alguma automação crítica de negócio — não só de código — a correr exclusivamente dentro de Actions ou de um runner externo, sem alternativa local?
E, se a autenticação de equipa depender de um fornecedor externo, há algum acesso de emergência que não passe por esse mesmo fornecedor? Não são perguntas retóricas — são o mesmo exercício que a PontoTi aplica à sua própria infra-estrutura.