O GitHub experimentou degradação multi-serviço ao longo de 28-29 de abril que tirou o GitHub Issues do ar por 20 horas 24 minutos, o GitHub Pages do ar por 20 horas 24 minutos, e o GitHub Actions do ar por 14 horas 6 minutos, segundo a própria página de status do GitHub rastreada pela StatusGator. Os relatos no DownDetector dispararam por volta de 9h05 CET em 28 de abril. O título publicado do incidente foi "Incomplete pull request results in repositories." A queda caiu na mesma semana em que o GitHub anunciou a mudança para preços AI Credits por uso para o Copilot — juntos, a semana torna o argumento "não dependa de um único host git" mais fácil de fazer do que há anos.
A duração importa mais do que o gatilho. Uma queda de 20 horas no Issues e no Pages, e 14 horas no Actions, tira grandes partes do fluxo de trabalho de desenvolvedores do ar. Issues é onde mora o tracking de bugs e a gestão de projetos para a maioria dos projetos open source. Pages é onde muitos projetos pequenos hospedam sua documentação e demos. Actions é o substrato CI/CD por baixo do grafo de distribuição de pacotes de facto do mundo — quando Actions está fora, pacotes não são publicados a partir de pipelines canônicas, pushes para o GitHub Container Registry falham, e qualquer projeto que amarrou o processo de release aos runners de Actions parou de releasear. O título raiz único — "Incomplete pull request results in repositories" — mascara a cascata: metadados relacionados a PRs alimentam triggers do Actions, que alimentam deploys do Pages, que alimentam fluxos de tickets do Issues. Quando a camada de dados de pull request balança, todo o grafo em cima balança.
O GitHub é o mais próximo de um ponto único de falha que o ecossistema de desenvolvedores tem. Existem cerca de 200 milhões de desenvolvedores no GitHub e uma fração não trivial do CI open source mundial roda no GitHub Actions. A história de confiabilidade desta semana é desconfortável: uma queda de Issues de 20 horas não é uma tropeção de 20 minutos, e a causa sendo um problema da camada de dados de PRs sugere que a falha foi mais profunda que ruído de infra. Combinado com o reset de preço do Copilot para AI Credits anunciado em 28 de abril, a semana se lê como "plataforma central com sistemas core frágeis também vai começar a cobrar mais pelas funcionalidades de IA." Espere um salto mensurável de interesse por GitLab, Codeberg, Forgejo e Gitea auto-hospedado nas próximas semanas. O salto não vai ser um êxodo em massa — os custos de troca são enormes — mas os mantenedores de projetos open source de alto tráfego vão começar a pensar mais a sério em mirrors e fallbacks.
Para os builders, três coisas para realmente fazer. Primeiro, audite a sua dependência de processo de release no GitHub Actions especificamente: se a sua pipeline de release de pacote, build de container, ou deploy de documentação só dispara quando os runners do Actions estão saudáveis, você tem um ponto único de falha escondido. Espelhe para um segundo provedor de CI (CircleCI, Buildkite, GitLab CI, runners auto-hospedados) para os trabalhos críticos, mesmo que mantenha o dia a dia no Actions. Segundo, faça push-mirror do seu repo para um segundo host. O setup de 90 segundos de um remote no GitLab ou Codeberg se paga na primeira vez que o GitHub Issues parar de aceitar escritas. Terceiro, o reset de preços do Copilot mais essa queda vai fazer com que "ferramentas de IA dev que funcionam offline ou em infraestrutura alternativa" virem um pitch mais convincente — observe lançamentos de produto no próximo mês que abrem com "o seu assistente de codificação IA roda na sua infra, não na do GitHub."