GitHub Actions e Pages estão enfrentando disponibilidade degradada

Artigo original ↗ Discussão no Hacker News ↗

Quedas frequentes e de várias horas no GitHub Actions e Pages estão levando muitos desenvolvedores e empresas a questionar a confiabilidade do GitHub, especialmente porque esses serviços estão no caminho crítico de CI/CD e deploys. Comentadores especulam causas que vão desde a migração para Azure e a carga explosiva impulsionada por IA até problemas organizacionais e culturais na Microsoft, ao mesmo tempo em que observam que os números oficiais de uptime e SLAs parecem desconectados da experiência real. Como resultado, um número notável está explorando ou migrando para alternativas como GitLab auto-hospedado, Forgejo, Woodpecker ou configurações de CI personalizadas para reduzir a dependência do plano de controle do GitHub.

Preocupações com Confiabilidade e Tempo de Atividade

  • Muitos comentaristas dizem que as quedas do GitHub Actions e Pages se tornaram frequentes, com usuários brincando que existe efetivamente “um nove” ou “zero noves” de uptime.
  • Rastreadores de uptime de terceiros citados mostram ~94–98% de disponibilidade em períodos recentes, em contraste com os números de SLA muito mais altos do próprio GitHub, levando a acusações de que as métricas oficiais são enganosas.
  • A duração deste incidente (cerca de um dia útil inteiro para alguns) e múltiplos incidentes nos últimos meses alimentam a sensação de que a confiabilidade está piorando, não melhorando.

Impacto no Usuário e Frustração

  • O trabalho fica bloqueado: CI não executa, PRs não conseguem fazer merge, hotfixes e releases para clientes atrasam, e incidentes em produção ficam mais difíceis de lidar.
  • As mensagens de erro são descritas como enganosas ou opacas, por exemplo, falhas que não indicam claramente “sem runners disponíveis”.
  • Algumas empresas sentem que não получают estabilidade extra apesar de pagarem, e que os mecanismos de suporte/crédito de SLA são fracos ou “esquemas” por design.

Causas Suspeitas

  • Duas teorias dominantes:
    • Crescimento massivo da carga, especialmente de agentes de IA e uso do Copilot, levando a 10–14× mais commits e >4× mais minutos de Actions, pressionando a arquitetura.
    • A migração em andamento da infraestrutura antiga/AWS do GitHub para Azure, com o Azure descrito como instável e politicamente imposto.
  • Muitos acreditam que carga e migração, além de lançamentos agressivos de recursos (especialmente IA/Copilot), estão interagindo de forma ruim.
  • Alguns argumentam que esses problemas refletem má liderança, prazos apressados e cultura de engenharia “performática”.

Arquitetura do Actions e Runners Auto-hospedados

  • Usuários se surpreendem que runners auto-hospedados também falhem, porque o agendador central e os webhooks caem.
  • Vários criticam o design: plano de controle centralizado como ponto único de falha, workflows pesados em YAML e estratégias ruins de degradação (sem shedding claro de carga ou prioridade para clientes pagantes).

Alternativas e Auto-hospedagem

  • Há forte interesse em mover CI para fora do GitHub: Jenkins auto-hospedado, GitLab, Forgejo, Gitea, Woodpecker, Buildkite, Argo e vários sistemas de CI de nicho são mencionados.
  • Alguns relatam boas experiências com GitLab/Forgejo auto-hospedados + runners (muitas vezes em um único servidor), alegando melhor confiabilidade e controle.
  • Outros observam que o lock-in de fornecedor e os custos de troca significam que o GitHub ainda “vence” apesar das quedas, especialmente por causa da UX de PR/revisão e dos efeitos de rede.

Comentários Mais Amplos

  • Os tópicos conectam os problemas do GitHub a preocupações mais amplas: “slop” de IA, pressão sobre RAM/datacenters, a qualidade dos produtos da Microsoft e os riscos de centralizar infraestrutura crítica de desenvolvimento em uma única plataforma proprietária.