GitHub sofre falha de duas horas em Pull Requests, Git Operations e Issues

O GitHub registrou uma falha de infraestrutura na manhã desta quarta-feira (4 de novembro de 2026) que degradou simultaneamente cinco componentes da plataforma: Git Operations, API Requests, Issues, Pull Requests e Actions. O status oficial do GitHub marca o início do monitoramento às 09:49 UTC (06:49 no horário de Brasília) e a resolução às 11:50 UTC (08:50 em Brasília), uma janela de pouco mais de duas horas.

Para quem depende do GitHub para trabalhar, isso não é um detalhe de rodapé: é o período em que git push, git clone, merge de Pull Request, abertura de Issue e execução de workflow do Actions puderam falhar ou atrasar sem aviso prévio, em qualquer repositório, de qualquer organização.

Como o incidente evoluiu

O GitHub publica atualizações de status incrementais, e o histórico desta falha mostra um quadro que foi se alastrando antes de ser contido:

• 09:49 UTC (06:49 BRT): início da investigação, com degradação relatada em Git Operations, Issues e Pull Requests.
• 09:50 UTC (06:50 BRT): Actions entra na lista, com performance degradada.
• 09:53 UTC (06:53 BRT): Pull Requests passa a reportar disponibilidade degradada, não só performance.
• 10:38 UTC (07:38 BRT): GitHub confirma "erros elevados e falhas intermitentes" afetando PRs, Git Operations e Issues, sem prazo definido para mitigação.
• 11:11 UTC (08:11 BRT): API Requests também aparece degradada.
• 11:17 UTC (08:17 BRT): equipe diz estar "trabalhando na mitigação", com requisições ainda podendo falhar ou atrasar.
• 11:30 UTC (08:30 BRT): primeira atualização de que a degradação em API Requests, Git Operations, Issues e Pull Requests foi mitigada; início do período de monitoramento.
• 11:43 UTC (08:43 BRT): Actions também é dado como mitigado.
• 11:50 UTC (08:50 BRT): incidente marcado como resolvido.

O próprio GitHub reconhece, no fechamento do incidente, que uma análise de causa raiz (RCA) será publicada separadamente, "assim que estiver disponível" — ou seja, o motivo técnico da falha segue em aberto no momento da resolução.

Por que afetou tanta coisa ao mesmo tempo

A lista de componentes atingidos (Git Operations, API Requests, Issues, Pull Requests e Actions) sugere uma falha em camada compartilhada da infraestrutura do GitHub, não em um serviço isolado. Quando Git Operations degrada, push e clone falham na raiz; quando API Requests degrada junto, qualquer integração que fale com a API do GitHub (bots de CI, ferramentas de review, dashboards internos) sente o impacto em cascata, mesmo sem usar diretamente os outros componentes listados.

Para quem monitora pipeline, o sintoma mais visível tende a ter sido Actions: workflows disparados por push ou por abertura de PR podem ter ficado presos em fila, falhado ao clonar o repositório, ou simplesmente não disparado, porque o evento de origem (push, Pull Request, Issue) também estava degradado.

O que fica sem resposta

O relatório do GitHub Status é operacional, não técnico: ele registra o quê e o quando, não o porquê. Não há, até a publicação deste incidente, indicação pública de:

• Se o problema teve origem em uma mudança de configuração, deploy ou falha de hardware/rede.
• Se algum dado chegou a ser perdido ou apenas atrasado (o texto fala em requisições que "podem falhar ou atrasar", sem detalhar persistência).
• Se o incidente teve relação com alguma região específica de infraestrutura ou foi global.

Em resumo: o GitHub confirma o impacto e a mitigação, mas deixa a causa raiz para um post-mortem futuro, prática comum em grandes provedores de nuvem após incidentes multi-componente.

O que isso muda pra quem usa GitHub no dia a dia

Duas horas de degradação intermitente em Git Operations e Actions tem efeito prático direto em times que dependem de CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps → contínuo: deploy bloqueado, merge de PR travado por check que nunca rodou, ou pipeline que falha por timeout de clone em vez de erro real no código. Vale, nesses casos, checar o status.githubstatus.com antes de sair depurando um workflow que na verdade está saudável.

Uma prática que ajuda a não piorar o próprio incidente: evitar retry agressivo e automático de jobs de Actions durante uma janela de degradação conhecida, já que isso só adiciona carga a uma infraestrutura que já está sob estresse. Times com deploy crítico também podem considerar ter um caminho de fallback manual (runner local, mirror do repositório) para não ficar inteiramente refém da disponibilidade do GitHub.com em janelas como essa.

O incidente reforça algo que todo time que depende de um provedor único de Git hospedado já sabe na teoria: Pull Requests, Issues e Actions compartilham infraestrutura, e um problema em uma camada de base pode derrubar os três ao mesmo tempo, mesmo que o código do seu repositório não tenha mudado nada.

Fonte: Hacker News