Um site rastreia os incidentes do GitHub e pergunta: a plataforma está "cooked"?

Um site chamado IsGitHubCooked virou tema de discussão entre desenvolvedores por fazer algo simples e incômodo: agregar o histórico público de incidentes do GitHub e permitir filtrar por serviço e severidade. A página foi ao topo do Hacker News e reacendeu a conversa sobre a confiabilidade da plataforma num momento em que a maioria dos times brasileiros roda build, deploy e revisão de código diretamente sobre ela.

O recorte importa porque, como o próprio autor explica na página, "everybody's reliability narrative is a function of the services they depend on and the 9's they expect". Quem só usa git push sente uma realidade; quem depende de GitHub Actions para deploy sente outra bem diferente.

O que os números mostram

Segundo o site, o GitHub acumula 1128 incidentes desde março de 2016. Nos últimos três meses, a média foi de 24 incidentes por mês (queda de 5% ante o trimestre anterior). A maior sequência sem incidentes foi de apenas 8 dias, encerrada em 31 de dezembro de 2025, e o pior mês registrado foi fevereiro de 2026, com 37 incidentes.

O dado mais relevante para quem constrói software é a disponibilidade por serviço nos últimos três meses. Os serviços que mais impactam pipeline de entrega aparecem no fim da lista:

Na outra ponta, Dashboard, Discussions, Docs e Mobile marcaram 100% de disponibilidade no período. A diferença entre um git clone (Git Operations, 99,49%) e uma esteira de deploy dependente de Actions (98,20%) é justamente o que o filtro do site tenta tornar explícito.

Quanto à severidade, dos incidentes catalogados 81% foram Minor, 16% Major e apenas 3% Critical (29 no total). O pior dia por contagem foi 9 de fevereiro de 2026, com 7 incidentes; o pior por tempo de indisponibilidade foi 16 de abril de 2025, com 1 dia e 2 horas de downtime.

Por que isso pesa no fluxo de quem trabalha no Brasil

O histórico também traz um recorte por dia da semana: quarta (22%), terça (21%) e quinta (19%) concentram a maioria dos incidentes, contra 4% no sábado e 2% no domingo. A leitura óbvia é que os problemas se concentram em horário comercial e alto tráfego, exatamente quando os times estão empurrando código.

Para o desenvolvedor brasileiro, o fuso amplifica o problema. A janela de maior atividade do GitHub coincide com a manhã e o início da tarde no Brasil, quando muitos times aqui estão em pico de commits e deploys. Um Actions instável nessa faixa significa build travado, release parado e revisão de PR emperrada bem no meio do expediente. Vale a pena revisar se pipelines críticos têm plano de contingência (runner self-hosted, mirror de repositório, ou capacidade de deploy manual) para os momentos em que o Actions cai.

A ressalva sobre "uptime médio"

O número que o site estampa é uma média sobre todo o período, e a comunidade foi rápida em apontar que isso pode mascarar a experiência real. No thread do Hacker News, o usuário kevmo levanta o ponto central:

"An important thing to consider is how much of their uptime without incidents is not the normal working hours. Their incident-free uptime on 9-5 EST, Mon-Fri, is probably like 60%."

kevmo

Ou seja: 98,20% de uptime somando madrugadas e fins de semana não descreve o que um time sente numa quarta-feira à tarde. Outro comentário, de bushbaba, foi mais direto ao ironizar que "could have been a page with a static 'Yes' and a significant portion of time it'd be accurate".

Houve também quem cobrasse rigor dos próprios números do site. O usuário JeremyHerrman apontou uma inconsistência aritmética na descrição: "1125 incidents / 126 months ≈ 8.9 incidents per month, not 24". A média de 24 se refere aos últimos meses, não à história inteira, o que reforça a importância de olhar o recorte temporal antes de sacar conclusões.

O contexto: migração para Azure e a era da IA

Parte da discussão liga a instabilidade recente à migração de infraestrutura do GitHub para o Azure↳Azure76 conteúdosDeploy de Azure Stream Analytics job com CI/CD usando Azure PipelinesDevSecOps · mai 2019Azure – Como criar uma base de dados SQL no Microsoft Azure pronta para ser utilizadaData · abr 2019Azure Static Web Apps com Vue.js e Visual Studio CodeDevSecOps · out 2023Ver tudo em DevSecOps → e ao volume gerado pela adoção de ferramentas de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →. O comentário mais votado nessa linha pede moderação nas críticas:

"You could justify the jabs when we could all blame any outage on the migration to Azure, but then they shared numbers around the scale they're dealing with now that everyone is constantly building and pushing with AI."

kashnote

Do outro lado do espectro, o usuário rvz usou o caso para reafirmar uma crítica antiga à centralização: "they were cooked the moment they got acquired by Microsoft", argumentando que concentrar todo o ecossistema numa única plataforma sempre foi arriscado.

O que fica em aberto

O IsGitHubCooked não é uma fonte oficial: ele consome o histórico público de status da própria plataforma e o reorganiza. Os números são úteis como termômetro, mas dependem de como cada incidente foi classificado e do período escolhido no filtro. O valor prático da ferramenta está menos no veredito ("cooked" ou não) e mais em permitir que cada time meça a confiabilidade dos serviços que de fato usa, em vez de discutir com base numa média genérica. Para quem depende de Actions ou Copilot no dia a dia, os dados são um lembrete concreto de que redundância no pipeline não é luxo.

Fontes: Hacker News · Reações no Hacker News