GitHub: Falha nas operações Git

• Em 18 de novembro de 2025 (UTC), o GitHub sofreu uma falha em todas as operações Git, interrompendo clientes SSH·HTTP e o acesso a arquivos brutos
• A causa do problema foi identificada como a expiração de um certificado TLS usado na comunicação entre serviços internos
• O GitHub substituiu o certificado expirado e reiniciou os serviços afetados, concluindo a recuperação total
• Depois disso, a empresa está reforçando os alertas de monitoramento de expiração de certificados e avançando na migração para automação para eliminar certificados gerenciados manualmente
• Esta indisponibilidade afetou as Git Operations e o Codespaces do GitHub, e após a recuperação todos os serviços voltaram ao estado normal

---

Relatório de falha nas operações Git

• Entre 20:30 e 21:34 UTC de 18 de novembro de 2025, o GitHub sofreu uma falha em todas as operações Git

  • As interações de clientes Git via SSH e HTTP, bem como o acesso a arquivos brutos, foram afetados
  • Produtos que dependem de operações Git também sofreram a mesma indisponibilidade

• A causa foi identificada como um certificado TLS expirado usado na comunicação entre serviços internos

  • O GitHub resolveu o problema substituindo o certificado e reiniciando os serviços afetados
  • Após a reinicialização dos serviços, a recuperação completa foi concluída

• Para evitar o mesmo problema no futuro, o GitHub está reforçando o sistema de alertas de expiração de certificados

  • Também está realizando monitoramento e verificações de automação em outros certificados da área relacionada
  • Está acelerando a eliminação dos certificados ainda gerenciados manualmente e a criação de um sistema automatizado de comunicação entre serviços

Andamento da falha e etapas de recuperação

• 20:39 UTC: reportada degradação de disponibilidade em operações Git e no Codespaces
• 20:52 UTC: confirmada falha em algumas operações Git via HTTP
• 21:11 UTC: confirmada falha em todas as operações Git
• 21:25 UTC: degradação de disponibilidade no Codespaces continua
• 21:27 UTC: causa identificada, correção em andamento
• 21:36 UTC: após a implantação da correção, início da recuperação parcial
• 21:55 UTC: todos os serviços normalizados, recuperação do Codespaces concluída
• 21:56 UTC: confirmada a operação normal das operações Git
• 21:59 UTC: encerramento do incidente e publicação do relatório

Serviços afetados

• Git Operations
  • Conjunto geral de operações Git baseadas em SSH e HTTP
• Codespaces
  • Houve degradação temporária de disponibilidade

Ações de acompanhamento

• Reforço no monitoramento de expiração de certificados e na automação
  • Estabelecimento de um sistema de alertas preventivos antes da expiração
  • Verificação dos processos de renovação automática de todos os certificados internos
• Ampliação da automação de segurança e operação
  • Eliminação do gerenciamento manual de certificados
  • Criação de comunicação automatizada entre serviços em conformidade com as práticas modernas de segurança

[GN⁺]

Comentários do Hacker News

• É preocupante como as principais falhas em sistemas de software parecem estar acontecendo com frequência demais
  No ano passado, houve apenas quatro incidentes que afetaram meu trabalho, mas neste trimestre já estamos no quarto
  Dá a sensação de que a resiliência do software de rede está desaparecendo aos poucos
  Nossa equipe usa uma arquitetura monolítica, mas tem muitas dependências como Redis, S3 e serviços externos de integração
  Por isso, documentamos as condições de falha, reforçamos a automação de testes e deploy e simplificamos a infraestrutura, inclusive migrando da nuvem para VPS
  Como resultado, o sistema ficou muito mais estável e previsível
  Sem esse tipo de trabalho chato, mas essencial, a complexidade só teria aumentado e o sistema ficaria ainda mais frágil
  Os incidentes recentes que enfrentei foram AWS us-east-1, Azure Front Door, Cloudflare e agora o GitHub

  • No fim, acho que o problema é dinheiro
    Os clientes não querem gastar com resiliência nem infraestrutura redundante
    Desde 2008 trabalhei em mais de dez projetos, e na maioria a postura era basicamente “vamos deixar na mão da sorte”
  • Concordo. O corte de custos está levando ao resultado de “esquecermos como construir sistemas que aguentam falhas”
  • Falando de forma deliberadamente provocativa, acho que o aumento do uso de LLMs também contribui para esse fenômeno

• Git é um sistema de controle de versão distribuído, então ainda dá para trabalhar sem o GitHub
  O GitHub é apenas um hub conveniente

  • Mas, se a empresa depende totalmente do GitHub Actions, fica completamente travada como agora
  • É uma situação tipo “esta escada rolante está temporariamente funcionando como escada. Pedimos desculpas pelo inconveniente”
  • A essência do problema é que o GitHub caiu, não o git em si
  • Sem o GitHub, perde-se a função de hub de colaboração com outras pessoas
  • O motivo de estarmos no Hacker News agora é que não estamos conseguindo trabalhar

• A falta de confiabilidade do GitHub parece séria
  Para quem depende de CI/CD, isso é fatal
  Internamente, parece que tratam isso só como “o CI/CD do nosso time quebrou”, sem a perspectiva de que “metade do mundo parou”
  Essa cultura de silos e a atitude de “não é problema nosso” acabam levando à queda de confiabilidade
  Além disso, por causa da posição dominante, os clientes acabam tendo que engolir isso
  É a mesma postura de “você não tem para onde ir mesmo” que eu já vi antes na Verio e na Verisign

• Fico me perguntando se as falhas em cloud/SaaS estão realmente mais frequentes hoje em dia
  Não sei se é só porque há mais cobertura ou se a frequência de fato aumentou
  Será que isso tem a ver com cortes de orçamento, redução de pessoal, adoção de IA ou crescimento excessivo?

  • A Microsoft parece acreditar que isso se resolveria se migrasse o GitHub para o Azure
  • Pelo tempo que uso, sinto claramente um aumento na frequência das falhas
    Antes era uma ou duas vezes por ano; hoje em dia é quase todo mês, e recentemente quase toda semana
  • Alguém disse, durante a falha da Cloudflare, que a “cultura de programação baseada em IA” está agravando esse tipo de problema
    Pequenos trechos de código gerados por IA podem causar falhas em efeito dominó
  • Como em um artigo da Techrights,
    acho que demissões em massa afetaram a confiabilidade
  • Por causa do FOMO causado pela IA, os cronogramas dos projetos ficam ainda mais apertados,
    e parece que os últimos 10% do trabalho de estabilidade acabam sendo ignorados

• Quando não consegui fazer push, no começo achei que o problema era meu
  No fim, resolvi desistir hoje e tentar de novo amanhã

  • A autenticação funcionava, mas o push não, e foi uma experiência realmente de arrancar os cabelos
  • Nem adicionar uma nova chave SSH resolveu. No começo só apareciam erros estranhos e depois veio a mensagem “upstream unhealthy”
  • Eu também quase acabei reconfigurando tudo do zero

• Eu já não estava com vontade de trabalhar hoje, e depois da Cloudflare agora o GitHub também caiu, então parece um sinal para simplesmente descansar

  • O problema é essa dependência tecnológica centralizada nos EUA
    Precisamos de mais soberania tecnológica e descentralização

• Entre os serviços que usei nos últimos 5 anos, o GitHub foi o mais instável
  Fico curioso se o GitLab é melhor. Minha confiança no GitHub agora está praticamente em zero

  • Na nossa empresa usamos GitLab self-hosted, mas o servidor Gitaly cai com frequência
    Parece ser por causa do ambiente com monorepo grande, mas claramente há problemas de escalabilidade
  • O GitLab tem muitos recursos, mas a integração é meio desajeitada e o acabamento deixa a desejar
    Mesmo assim, é uma vantagem ter repositório, CI/CD, issues e wiki em um só lugar
  • Uso tanto GitHub.com quanto GitLab self-hosted,
    e o GitHub é vulnerável a falhas de nuvem, enquanto o GitLab sofre bastante com interrupções em upgrades automáticos
    Cada um tem seus prós e contras
  • O problema do GitLab é que ele é lento e pesado
    Ele carrega vários MB de JS, então em redes lentas as páginas quase nem abrem
  • Em on-premises, dá para garantir o nível de estabilidade que você quiser

• Em situações de emergência, dá para editar arquivos diretamente pela interface web do GitHub
  Mas o actions/checkout@v4 do GH Actions não está funcionando agora por causa do problema com git

  • Na verdade, é possível fazer git push/pull por qualquer host com SSH habilitado
  • A gente também estava no meio de um hotfix em produção e ficou bloqueado. Não sei o que está acontecendo com a internet ultimamente
  • O CircleCI também está falhando em operações git por problemas para reconhecer chaves SSH do GitHub
  • Desta vez, a IA do GitHub mandou verificar o githubstatus.com, então surpreendentemente ajudou
  • Fico curioso se dá para criar branches pela interface do GitHub

• Ao longo dos últimos 10 anos, alternando entre grandes empresas e startups, vi um padrão recorrente
  startup → atendimento a clientes enterprise → redesenho complexo → idealismo → busca por lucro → produto inchado → saída de engenheiros-chave → queda de qualidade
  Esse ciclo também se repete nas grandes empresas de cloud (AWS, Cloudflare, GCP etc.)
  Internamente, cada serviço também é dividido em pequenas unidades de negócio que operam com foco em lucro
  No fim, até a infraestrutura básica está sendo enfraquecida pela pressão por rentabilidade
  Acho perigosa a crença de que “AWS ou GCP são grandes demais para falhar”

  • Concordo. No processo de atender clientes enterprise, é inevitável que o produto fique mais complexo e lento
    Mas a dívida técnica e os problemas de segurança das startups iniciais também eram sérios
    No fim, é natural que as rachaduras do sistema apareçam durante o crescimento em larga escala

• A página de status do GitHub voltou a mostrar a frase “alguns usuários podem estar enfrentando problemas”
  Mas, na prática, não é só HTTPS: todo push via SSH também está falhando

  • Parece que os responsáveis pela página de status não conseguem sair da expressão “alguns usuários”
    Uma divulgação transparente, em vez desse eufemismo de RP, aumentaria mais a confiança
    Além disso, as atualizações da página de status muitas vezes também demoram
  • Um amigo meu disse que conseguiu fazer push por um instante, mas a maioria continua em estado de erro fatal