Vários incidentes de indisponibilidade em serviços do GitHub

 (githubstatus.com)
2 pontos por GN⁺ 5 일 전 | 1 comentários | Compartilhar no WhatsApp
  • Houve degradação de disponibilidade e indisponibilidade em vários serviços do GitHub, incluindo Webhooks, Actions e Copilot
  • Inicialmente, foi investigada a degradação de disponibilidade de Copilot e Webhooks e, depois, o escopo da investigação foi ampliado para vários incidentes em serviços
  • O Actions sofreu degradação de desempenho separadamente e, após a identificação do problema raiz, foi iniciado o trabalho de mitigação
  • Depois que a degradação em Actions e Copilot foi mitigada, o monitoramento de estabilidade continuou, junto com o trabalho de validação dos serviços restantes, e o Webhooks também voltou ao funcionamento normal
  • No fim, este incidente foi encerrado com status de resolvido, e uma análise detalhada da causa raiz será compartilhada assim que estiver pronta

Evolução do incidente

  • Ocorreram falhas em vários serviços do GitHub, incluindo Webhooks, Actions e Copilot no escopo afetado
  • Inicialmente, começou a investigação da degradação de disponibilidade de Copilot e Webhooks
  • Depois, vários serviços passaram a apresentar indisponibilidade, ampliando o escopo da investigação
  • O Actions sofreu degradação de desempenho separadamente, e a apuração da causa continuou
  • Após a identificação do problema raiz, foi iniciado o trabalho de mitigação
  • A degradação que afetava Actions e Copilot foi mitigada, e o monitoramento para manter a estabilidade continuou
  • Depois da mitigação em muitos serviços, também continuou o trabalho de validação dos serviços restantes
  • O Webhooks também voltou ao funcionamento normal
  • Por fim, este incidente foi encerrado com status de resolvido, e uma análise detalhada da causa raiz será compartilhada assim que estiver pronta

Links de referência

Leituras relacionadas

1 comentários

 
GN⁺ 5 일 전
Opiniões no Hacker News

  • Eu estava no processo de migrar várias coisas para self-hosting em casa e ontem finalmente terminei de montar uma instância do Forgejo dentro de casa
    Linux e Windows em VMs, macOS em um Mac Mini, com runners de CI/CD também, então agora o código-fonte, as Actions e a infraestrutura real estão todos literalmente dentro de casa
    Normalmente leva um ou dois meses depois de migrar para self-hosting até bater aquela sensação de satisfação, mas dessa vez já no dia seguinte ao fim da migração eu senti convicção de que tinha feito a escolha certa, então fiquei bem contente

    • A ideia de homelab sempre me atrai, mas quando começo a montar um eu me canso rápido
      Depois de passar o dia inteiro no trabalho consertando sistemas quebrados, não quero chegar em casa e assumir também o papel de meu sysadmin pessoal
      Tenho um Minisforum bom e potente que comprei no Natal em cima da mesa, mas ainda nem liguei ele
    • Quando você começa com self-hosting, percebe imediatamente o quanto a web moderna é lenta
      Eu rodo o Forgejo junto com vários serviços em um NUC e no Proxmox, e o carregamento de páginas fica em torno de 6 ms
      O Immich não é tão rápido assim, mas ainda é muito mais rápido que o Google Photos
    • Há um tempo mantenho um Forgejo pessoal e coloco todos os meus side projects privados lá
      A UI é parecida no geral, mas a experiência é muito mais agradável do que no GitHub. O fato de o uptime passar de 90% já quase basta como explicação
      Tenho enfrentado problemas com o GitHub com frequência demais ultimamente, e até navegar pelo site costuma ser lento ou simplesmente travar
    • Eu também fiz essa migração recentemente, e o que mais me surpreendeu foi que a velocidade das Actions é muito maior do que no GitHub
      Configurei Linux e macOS com um Mac Mini e um arquivo de tasks do Ansible gerado pelo Claude, mas montar a VM de Windows parecia bem doloroso
      Queria saber se você encontrou alguma forma de simplificar o processo de implantação
    • Ontem vi aqui uma discussão sobre gitea, pesquisei um pouco e também migrei imediatamente para self-hosting, transferindo todos os meus projetos pessoais para o Forgejo
      Só que projetos públicos são mais difíceis de mover por causa do mercado de trabalho e do efeito de rede do GitHub
      Agora estou rodando algo como 20 serviços locais por causa das coisas de que preciso e me sinto brincando de administrador de sistemas; o mais importante é que agora a responsabilidade de evitar perda de dados é minha, então ter backups regulares é essencial

  • Em https://mrshu.github.io/github-statuses/ o uptime caiu para 88,15%
    Mesmo olhando por componente individual, o melhor fica em 99,78%, então mal chega ao nível de two nines

    • A escala de crescimento com que eles lidam é absurdamente grande
      Em 2025 eram 1 bilhão de commits, agora são 275 milhões de commits por semana e, assumindo crescimento linear, isso dá um ritmo de 14 bilhões de commits neste ano
      O GitHub Actions também passou de 500 milhões de minutos por semana em 2023 para 1 bilhão de minutos por semana em 2025, e nesta semana já está em 2,1 bilhões de minutos até agora
      A fonte é uma postagem de 2026-04-03 da COO do GitHub: https://x.com/kdaigle/status/2040164759836778878
    • Fico curioso se isso tem correlação com o fato de o GitHub ter começado a priorizar a migração para Azure
      https://thenewstack.io/github-will-prioritize-migrating-to-azure-over-feature-development/
    • A IA que a Microsoft está empurrando acaba sendo uma baita ajuda para quem faz self-hosting e para os entusiastas de Linux

  • Fico me perguntando se, mesmo com essas falhas repetidas, o GitHub está realmente sofrendo perdas significativas de negócio
    Por muito tempo a indústria dizia que confiabilidade e valor de marca eram essenciais, mas hoje parece que quase ninguém liga para isso
    Se minha percepção estiver errada, eu aceito ser corrigido na hora

    • Só 2 ou 3 anos atrás, quase todo mundo concordava que, para entregar software de forma estável e segura, eram indispensáveis repeatable builds, chain of custody verificada e bill of materials auditável
      Mas bastou os LLMs melhorarem um pouco para parecer que esse papo sumiu por completo
    • O GitHub já está enraizado demais como plataforma, então essas falhas acabam sendo tratadas como custo do negócio
      Grandes empresas têm alguma proteção com instâncias internas, e o resto ou não é tão afetado assim, ou não tem recursos para construir uma solução própria ou migrar
    • Ir do GitHub para o GitLab pode ser como sair da frigideira e cair no fogo
      Seria bom se existisse uma alternativa realmente boa para quem usa isso em escala

  • Pela janela móvel de 90 dias, para cair abaixo de two nines deve bastar mais umas 16 horas de falha

  • Para não dizer que não há motivo de preocupação, a status page continua dizendo que está tudo verde, 100% operacional
    Isso apesar de nem dar para acessar uma página estática

  • Já está num ponto em que devia surgir um post no HN toda vez que houvesse um dia sem problemas nos serviços do GitHub
    Ou então isso só quer dizer que o estado atual virou o normal

  • No passado, o pessoal do Bitbucket chegou a perder um dia inteiro de git history em vários repositórios
    Foi mais um problema de dados deles do que downtime; graças aos clones locais conseguimos recuperar a maior parte, mas as issues e PRs daquele período simplesmente sumiram
    Foi por isso que comecei a criar o gitbacker como side project
    Fazer backup do repositório em si é fácil; a parte realmente interessante é o backup dos metadados

  • Hoje houve outro incidente muito sério: https://www.githubstatus.com/incidents/zsg1lk7w13cf
    Por causa de uma regressão ao usar merge queue com squash merge ou rebase, alguns PRs foram mesclados incorretamente entre 2026-04-23 16:05 e 20:43 UTC
    No nosso caso, cerca de 8 commits foram revertidos por completo da branch principal nesse período
    Foi a primeira vez que vi um incidente do GitHub tão grave assim

    • Downtime é um tipo de problema, mas reverter silenciosamente commits da branch principal é um nível completamente diferente de falha
    • Aqui foi parecido
      É irônico que uma ferramenta feita justamente para evitar merge conflicts estivesse escrevendo commits quebrados direto na branch principal
    • Aqui também vários commits sumiram da main, enquanto os PRs continuavam marcados como merged
      Foi extremamente estressante
    • Aqui também tivemos PRs revertidos em vários repositórios
      Downtime já é um problema, mas reverter PRs é uma falha um nível acima
    • Nós também recebemos um e-mail com PDF em anexo contendo a lista de commits afetados e instruções de recuperação
      Foi um caos completo

  • Nossos requisitos são relativamente simples, algo como git repos + actions, e os downtimes ocasionais não são totalmente críticos porque não somos um time que faz commit e deploy o tempo todo
    Mesmo assim, agora estamos procurando alternativas com seriedade
    Coincidentemente, talvez por causa da corrida de gente atrás de alternativas, o SourceHut também caiu. Estava fora do ar quando este comentário foi escrito e agora já voltou
    https://sr.ht/

    • Talvez valha olhar o tangled.org

  • Só hoje já houve três incidentes, cada um com quase mais de uma hora, mas o status diário aparece todo verde e com nenhum downtime registrado
    Nem parece algo essencialmente diferente dos incidentes antigos que ganhavam barra vermelha; a única diferença é que não duraram várias horas
    Então eu realmente não sei o que essa barra verde quer dizer
    Fico em dúvida se só muda para não verde quando gente suficiente reclama, ou se os incidentes do próprio dia aparecem só temporariamente no tooltip e depois são discretamente esquecidos
    Como até agora as datas verdes não mostram nenhum incidente no tooltip, mas hoje aparecem vários, de qualquer forma isso parece uma apresentação deliberadamente enganosa