Atualização sobre a disponibilidade do GitHub
(github.blog)- Após duas falhas recentes, o GitHub está tratando a disponibilidade como prioridade máxima e revisando novamente sua infraestrutura e arquitetura para acompanhar o aumento acelerado das cargas de trabalho de desenvolvimento e dos agentic development workflows
- Um único pull request se conecta amplamente a repositórios Git, Actions, busca, notificações, permissões, webhooks, APIs, trabalhos em segundo plano, caches e bancos de dados, então pequenas ineficiências podem crescer e levar a acúmulo de filas e propagação de dependências
- No curto prazo, o foco está em reduzir gargalos e carga no banco de dados com a migração do backend de webhooks, o redesenho do cache de sessão de usuários, ajustes nos fluxos de autenticação e autorização e expansão de computação baseada em Azure
- No longo prazo, a empresa está aumentando a resiliência e a flexibilidade por meio do isolamento de serviços centrais, redução de pontos únicos de falha, migração de partes do monólito em Ruby para Go, transição para public cloud e criação de caminhos de multi cloud
- Tanto a regressão da merge queue de 23 de abril quanto a sobrecarga do Elasticsearch de 27 de abril não causaram perda de dados, e o GitHub também está reforçando a transparência ao incluir métricas de disponibilidade na status page e ampliar a divulgação até de falhas menores
Contexto da resposta sobre disponibilidade
- O GitHub organizou o status dos trabalhos de melhoria de disponibilidade e confiabilidade após duas falhas recentes
- Desde outubro de 2025, a empresa vem executando um plano de expansão de capacidade em 10 vezes e, em fevereiro de 2026, ficou claro que seria necessário projetar assumindo uma escala 30 vezes maior que a atual
- A principal razão é a mudança na forma de desenvolver software, e os agentic development workflows aceleraram rapidamente desde o segundo semestre de 2025
- Criação de repositórios, atividade em pull requests, uso de APIs, automação e cargas de trabalho em repositórios grandes estão crescendo rapidamente
Pressão estrutural revelada no processo de expansão
- Um único pull request pode acionar ao mesmo tempo repositórios Git, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches e databases
- Em grande escala, até pequenas ineficiências se acumulam e podem levar a acúmulo de filas, transferência de carga para o banco por causa de cache misses, atraso de indexação, amplificação de tráfego por retries e impacto de dependências lentas em vários produtos
- A prioridade foi organizada como disponibilidade primeiro, depois capacidade e só então novos recursos
- O trabalho em andamento combina redução de tarefas desnecessárias, melhorias de cache, isolamento de serviços centrais, eliminação de pontos únicos de falha e migração de caminhos sensíveis a desempenho para sistemas dedicados
- A tarefa central passou a ser reduzir acoplamentos ocultos, limitar o blast radius e garantir graceful degradation para que a pressão em um subsistema não derrube o todo
Melhorias em andamento
- No curto prazo, o foco está em eliminar gargalos que apareceram mais rápido do que o esperado
- O GitHub moveu os webhooks para um backend fora do MySQL, redesenhou o cache de sessão de usuários e também revisou os fluxos de autenticação e autorização, reduzindo bastante a carga no banco de dados
- Aproveitando a migração para Azure, a empresa também garantiu mais recursos de computação
- Depois disso, o foco passou para o isolamento de serviços centrais como git e GitHub Actions e para a redução de pontos únicos de falha
- A equipe analisou com granularidade dependências e camadas de tráfego para identificar o que precisava ser separado e priorizou as ações por risco, com o objetivo de minimizar o impacto de vários tipos de ataque sobre o tráfego normal
- Também foi acelerado o trabalho de migrar parte do código mais sensível a desempenho e escala do monólito em Ruby para Go
- Enquanto avançava na mudança de pequenos datacenters próprios para public cloud, o GitHub também começou a desenvolver, pensando mais no longo prazo, caminhos de multi cloud
- Essa medida de longo prazo é necessária para garantir a resiliência, a baixa latência e a flexibilidade que serão exigidas daqui para frente
Repositórios grandes e resposta à merge queue
- O GitHub aponta o aumento de grandes monorepos como um desafio de escala ainda mais difícil do que o crescimento no número de repositórios
- Nos últimos três meses, a empresa ampliou fortemente os investimentos para responder a essa tendência tanto no sistema de git quanto na experiência de pull request
- Também está em andamento um trabalho relacionado ao novo desenho de APIs para mais eficiência e escalabilidade, que será divulgado em um post separado no blog
- Como isso é importante para repositórios que recebem milhares de pull requests por dia, a empresa também está investindo em otimização do processamento da merge queue
Incidente recente 1: problema na merge queue em 23 de abril
- Em 23 de abril, ocorreu uma regressão no funcionamento da merge queue de pull requests
- Em merge queues que usam squash merge, quando um merge group incluía dois ou mais pull requests, era gerado um merge commit incorreto
- Nos casos afetados, as mesclagens seguintes acabavam revertendo sem intenção as alterações do pull request mesclado anteriormente e de commits já existentes
- Durante o período afetado, 658 repositórios e 2.092 pull requests foram impactados
- Como os números iniciais foram estimados de forma conservadora, os valores compartilhados no começo eram um pouco maiores
- Pull requests mesclados fora da merge queue não foram afetados, e grupos de merge queue que usavam merge ou rebase também não foram impactados
- Não houve perda de dados. Todos os commits permaneceram armazenados no Git
- No entanto, o estado da branch padrão dos repositórios afetados ficou incorreto, e não era possível recuperar todos os repositórios de forma automática e segura
- incident root cause analysis: é possível ver mais detalhes adicionais
- Esse incidente expôs várias falhas de processo, e o GitHub está mudando esses processos para evitar a repetição do mesmo tipo de problema
Incidente recente 2: problema relacionado à busca em 27 de abril
- Em 27 de abril, ocorreu uma falha no subsistema de Elasticsearch responsável por várias experiências baseadas em busca
- O escopo do impacto incluiu algumas UIs baseadas em busca de pull requests, issues e projects
- A análise de causa raiz ainda está sendo finalizada e será publicada em breve
- Pelo que foi identificado até agora, o cluster entrou em estado de sobrecarga e, como resultado, deixou de retornar resultados de busca
- Entre as possíveis causas da sobrecarga, segue aberta a hipótese de botnet attack, mas a análise de causa raiz ainda não foi concluída
- Não houve perda de dados e operações de Git e APIs não foram afetadas
- Ainda assim, algumas UIs que dependem de busca deixaram de exibir qualquer resultado, causando grande confusão
- Essa era uma área em que o isolamento completo para eliminar pontos únicos de falha ainda não havia sido concluído, e antes disso outras áreas tinham prioridade de risco mais alta
- O GitHub está aplicando o mesmo tipo de análise de dependências e trabalho de redução de blast radius para diminuir a probabilidade e o impacto desse tipo de falha
Reforço da transparência sobre incidentes
- Ficou claro que os clientes queriam mais transparência durante incidentes
- Recentemente, a GitHub status page foi atualizada para incluir métricas de disponibilidade
- Além de grandes incidentes, o GitHub decidiu publicar também falhas menores no status, para que os usuários não precisem ficar tentando adivinhar se o problema está do lado deles ou do lado do GitHub
- A forma de classificar incidentes também continua sendo aprimorada, para facilitar o entendimento da escala e do alcance
- Também está em andamento um trabalho para melhorar como os clientes compartilham sinais e reportam problemas durante incidentes
Compromisso daqui para frente
- O GitHub promete melhorar a disponibilidade, ampliar a resiliência, escalar para o tamanho do desenvolvimento de software do futuro e comunicar-se com mais transparência
- O número de repositórios afetados pelo incidente de 23 de abril foi atualizado com base em 28 de abril de 2026
2 comentários
Como houve erros demais, pelo visto eles acabaram publicando um aviso às pressas. Mas também fico pensando se não demoraram demais... Já estão dizendo que houve tantos erros que todo mundo está abandonando a plataforma ;_;
Comentários do Hacker News
O GitHub já teve dezenas de incidentes só neste ano, e a disponibilidade e a confiabilidade pioraram visivelmente em relação ao ano passado.
A esse ponto, a situação já é séria o bastante para merecer dashboard e heatmap, e parece que a instabilidade do GitHub já virou meme em lugares como HN e Reddit.
Mesmo assim, dizer que a prioridade é "availability, capacity, new features" mostra uma leitura muito frouxa da realidade.
Agora a prioridade 1, 2 e 3 deveria ser toda availability, e por pelo menos 6 meses eles não deveriam falar de outra coisa além de consertar isso.
Há 6 meses diziam que a migração para Azure era a prioridade máxima e que por isso iam adiar o desenvolvimento de funcionalidades, mas agora dizem que a prioridade máxima é disponibilidade, então a história não fecha muito bem.
Na época, falaram que as restrições de capacidade do datacenter da Virgínia por causa da demanda de AI e Copilot eram "existential", então ver a empresa ainda tropeçando exatamente no mesmo problema torna tudo ainda mais absurdo.
Dizem que o desenvolvimento de funcionalidades foi adiado, mas toda semana continuam saindo recursos novos e mudanças de UI, e pouco tempo atrás também mudaram a visualização única de issues.
É difícil acreditar que uma empresa com os recursos da Microsoft continue emperrando sempre no mesmo ponto, e a estratégia de comprar serviços populares para desenvolvedores e mover tudo para a mesma plataforma também parece preocupante.
Em grandes organizações de engenharia, as prioridades não são excludentes, e times que não conseguem contribuir diretamente para a prioridade principal podem continuar trabalhando em outras funcionalidades.
https://news.ycombinator.com/item?id=47912521
Hardware dedicado tende a ser mais previsível do que cloud, e uma decisão do tipo "em vez de ir para Azure, vamos só comprar mais alguns racks" talvez nem pudesse ser tomada pela própria liderança do GitHub.
GitHub não é um site que precise ser redesenhado a cada 5 minutos, e às vezes parece que administradores estão empurrando funcionalidades novas só para justificar a própria existência.
O resultado é que, quanto mais quebram as coisas, mais isso acaba tendo efeito contrário para atrair usuários.
A busca também foi fortemente nerfada, e não entendo por que todo mundo continua estragando buscas que antes funcionavam bem, como aconteceu com Google Search ou YouTube.
Além disso, a Microsoft tem tanto o quase abandonado Azure DevOps quanto o GitHub, e eu odeio os dois, especialmente o sistema de tickets.
Eu já estava cansado de cada projeto no Jira ter configurações diferentes, mas agora já cheguei ao ponto de dizer "até sinto falta do Jira".
Aquele texto dá a sensação de ser difícil de ler com seriedade.
Gráficos sem rótulo com números enormes, prioridades que não batem com a experiência real e uma postura que não reconhece direito o uptime terrível dos últimos 12 meses incomodam bastante.
Embora falte o rótulo do eixo no canto inferior esquerdo, a mensagem principal — que a velocidade de crescimento de 2023→2024→2025→2026 é muito rápida — ainda é transmitida.
Dá para ler como se no começo ou no fim de 2026 eles estivessem falando de um crescimento maior do que a soma dos 3 anos anteriores, e mesmo sem os números do eixo dá para ver a tendência geral.
É preciso assumir que se trata de um gráfico linear, mas nesse contexto essa suposição não parece exagerada.
Se é uma empresa passando por um crescimento muito acima do planejado, problemas de capacidade são inevitáveis, e agora parece que eles precisam ir além de simplesmente colocar mais hardware e partir para eficiência de backend.
Os objetivos listados também parecem mirar majoritariamente nessa direção.
https://x.com/kdaigle/status/2040164759836778878
Não sei se a pessoa não acredita que o crescimento atual é exponencial, ou se acha que crescer 10x ao ano não é tão difícil assim.
https://damrnelson.github.io/github-historical-uptime/
Quando dizem que "iniciaram um caminho multi cloud", isso soa quase como uma admissão de que a Microsoft não consegue tirar do Azure sozinho o nível de confiabilidade que quer.
Pode ajudar a segurar retenção.
A ideia original era operar tudo com pouquíssima intervenção humana, mas hoje em dia o procedimento cotidiano seria alguém etiquetar racks ou VMs com números de série e mexer manualmente nas coisas.
Não consigo achar o link agora.
Entre segunda e quinta, das 9h às 11h no horário do Pacífico, costuma haver os leitores mais ativos, e nos fins de semana há menos concorrência, mas também menos engajamento.
O CTO do GitHub também está no conselho do Codepath.org, e se a descrição lá é algo como "formar a primeira geração AI-native de engenheiros, CTOs e fundadores", já dá para ter uma ideia de onde está o problema.
Pela minha experiência, a estabilidade do GitHub piorou bastante, e recentemente ficou difícil confiar até nos dados mostrados na web.
Desde ontem, eu e alguns colegas confirmamos que a lista de PRs aparece incompleta em vários repositórios.
Por exemplo, em https://github.com/gap-system/gap/pulls a aba mostra "Pull requests 78", mas na visualização da lista aparecem só "35 open".
O número 78 está correto, e isso também pode ser confirmado com
gh pr list, mas mesmo assim https://www.githubstatus.com continua mostrando "all systems operational".Pela CLI a lista aparece, mas no caminho web que passa pela busca eles simplesmente somem todos.
O suporte até reconheceu o problema, mas depois disso ficou quieto, e na página de status não há nada além de um problema do dia 27 que talvez esteja relacionado.
Em alguns repositórios parece ter sido resolvido no meio do caminho, mas continua reproduzindo em várias orgs e repos.
https://github.com/orgs/community/discussions/193388
Acabei encontrando os PRs faltando ao vasculhar a página de branches.
Talvez nem seja exatamente um bug completo, mas uma escolha de produto muito ruim para reduzir carga na infraestrutura.
Ainda assim, foi interessante ver a divulgação de novos dados de repos/issues/commits dos últimos anos.
Como muita gente já suspeitava de fora, isso confirma que os agentes estão impondo uma carga adicional repentina e grande ao GitHub.
É como atender uma base de usuários já gigantesca e, ao mesmo tempo, crescer exponencialmente como uma startup, então é inevitável virar alvo, e também não deve ser fácil para a organização se mover rápido.
Por outro lado, eles também têm muito mais talento, infraestrutura e capital do que uma startup.
Há só um gráfico sem rótulo e os números atuais de pico.
Não faço ideia do que fizeram com aqueles gráficos, parecem quase impressionismo de artista.
No gráfico de commits, por exemplo, não dá para entender por que aparece um grande degrau seguido de uma queda suave, por que esse degrau não acontece num ponto consistente, nem por que um salto maior às vezes vem com uma inclinação menor.
Os outros gráficos também se movem em formatos totalmente diferentes, o que deixa tudo ainda mais estranho.
Não servem para mostrar dados reais nem o significado dos dados, só para transmitir a ideia de que "alguma coisa está subindo".
Acho que federated forges são o futuro no fim das contas.
Os repositórios ficariam hospedados cada um em sua própria sovereign infra, com IDs globais e metadados federados de issues, PRs e afins por cima.
Esse tipo de índice global também é fácil de levantar, então disponibilidade deixaria de ser uma grande preocupação, e nós mesmos estamos trabalhando nessa direção.
No fim, ao usar hospedagem de terceiros, provavelmente voltariam a surgir 1 a 3 grandes provedores.
E mesmo fazendo self-hosting para escapar de problemas de disponibilidade, se suas dependências estiverem ligadas a um grande serviço como GitHub, a indisponibilidade de lá continua inevitável.
Então a solução prática continua sendo, como hoje, fazer proxy ou espelhamento de tudo que você usa.
Você pode ter o mesmo repo no GitHub, Codeberg e self-hosted, e só manter consistência no branch principal.
Depois disso, dá para atualizar de qualquer lugar, e basta deixar os links bem colocados no README.
Se eu pudesse conectar outro forge que oferecesse uma API decente ou webhook e ter a mesma conveniência, eu iria todo para self-hosting.
Do lado dos agentes, eles também precisariam abrir a interface, mas com uma arquitetura de plugins talvez desse para remover a dependência do GitHub e deixar o resto para MCP ou skills.
Eu não me importo de self-hostar runners grandes, então recentemente migrei para o Codeberg, e para jobs pequenos de cron uso os runners oferecidos pelo Codeberg.
Lá eles até têm lazy runner para esse tipo de uso.
O que está acontecendo agora parece ser isso.
Os subsídios de tokens já sugaram dados de treino suficientes, e o negócio dos agentic junkies já cresceu o bastante para girar o próprio flywheel, então agora parece que vão cortar isso e limpar os produtos que induzem prejuízo.
https://news.ycombinator.com/item?id=47923357