Se você já travou o coração ao ver “Partial Outage” no painel de status do GitHub minutos antes de um release crítico, pode respirar aliviado. A plataforma, que hospeda mais de 100 milhões de repositórios e é o pilar de incontáveis pipelines de CI/CD, acaba de anunciar um pacote de transparência que refina a forma como incidentes são classificados e exibidos. A mudança, válida a partir de abril de 2026, traz três novidades que prometem reduzir a ansiedade de devs e equipes de infraestrutura.
1. Novo nível de severidade: “Desempenho Degradado”
Até ontem, qualquer soluço – mesmo que leve – era automaticamente rotulado como Partial Outage. Isso gerava a impressão de que o serviço estava praticamente fora do ar, ainda que apenas uma fração de usuários percebesse lentidão ou erros intermitentes. Com o novo estado “Degraded Performance”, o GitHub passa a operar em um sistema de três camadas:
- Desempenho Degradado: serviço funcional, mas com latência acima do normal ou falhas pontuais.
- Partial Outage: parte significativa do serviço indisponível para um contingente relevante de usuários.
- Major Outage: indisponibilidade quase total.
Na prática, isso significa que pequenas oscilações, como picos de 500 ms a mais no GitHub Actions ou falhas temporárias ao criar issues, serão sinalizadas de forma menos alarmista. Para quem automatiza deploys com GitHub Actions ou sincroniza branches em tempo real, a distinção ajuda a decidir se vale a pena pausar o fluxo ou seguir em frente.
2. Uptime por serviço em tempo real (e com matemática honesta)
Sabe aquele número “99,9 % de disponibilidade” que sempre parece mágico? Agora ele ficará bem mais transparente. O GitHub começa a exibir porcentagens de uptime dos últimos 90 dias para cada componente – repositórios, Issues, Actions, Packages e afins – calculadas com pesos diferentes para cada severidade:
- Major Outage: 100 % do tempo entra como downtime.
- Partial Outage: contabiliza 30 % do intervalo afetado.
- Desempenho Degradado: não impacta o uptime, pois o serviço segue utilizável.
Exemplo prático: se o GitHub Actions ficou 1 hora em Partial Outage em três meses, isso equivale a 18 minutos de “queda” nos cálculos. Resultado mais fiel, menos ruído.
3. Copilot ganha diagnóstico dedicado para modelos de IA
O GitHub Copilot evoluiu: são vários modelos de IA operando em paralelo – do GPT-4 Turbo, da OpenAI, a LLMs proprietários da Microsoft. Antes, qualquer problema em um modelo disparava um incidente geral de Copilot. Agora, surge o componente Copilot AI Model Providers. Se apenas o GPT-4 ficar indisponível, você será informado diretamente ali e poderá alternar para outro modelo ou deixar o auto selection cuidar da escolha.
Por que isso importa para devs e equipes de produto?
• Planejamento de sprint: releases não precisam mais ser adiados por um alerta exagerado.
• Monitoramento externo: Ferramentas como Datadog e StatusCake podem consumir os novos dados de uptime para alertas mais precisos.
• Decisão de arquitetura: times que avaliam migrar para GitLab ou Bitbucket agora têm números mais objetivos para comparar.
Imagem: Internet
Visão de mercado: tendência de “observabilidade de plataforma”
O movimento do GitHub segue a onda de observability by design, já vista em serviços como AWS Health Dashboard e Cloudflare Status. A lógica é simples: quanto mais granularidade, menor o tempo médio de resolução (MTTR) – e, no fim, mais confiança para adotar a plataforma como backbone de produção.
Para quem mantém um parque de microsserviços escalando em GPUs ou processadores de última geração (confira nossa curadoria de hardware na Amazon), saber exatamente quando e quanto o repositório, o pipeline ou o assistente de IA ficaram indisponíveis faz toda a diferença no TCO do projeto.
O que esperar nos próximos meses
A GitHub Inc. promete continuar refinando o painel com novos componentes e métricas. Um passo plausível é a abertura de uma API pública para que equipes de SRE pluguem o status direto em seus dashboards Grafana ou Prometheus. Se isso acontecer, o ecossistema ganha ainda mais transparência – e nós, devs, ganhamos noites de sono mais tranquilas.
No fim das contas, a mensagem é clara: transparência virou feature crítica. E, quando o assunto é infraestrutura que sustenta milhões de linhas de código, cada milissegundo (e cada insight) conta.
Com informações de GitHub Blog
