O histórico de tempo de atividade do GitHub

• Página que visualiza o tempo de atividade mensal do GitHub de 2016 a 2026
  • Todos os dados são baseados em registros coletados da página oficial de status
• Estrutura que permite ver separadamente a taxa média de atividade (Average) e o detalhamento das interrupções (Breakdown)
• É possível acessar diretamente a fonte dos dados originais (View source) na própria página
• Material de visualização que permite verificar rapidamente a tendência de estabilidade do serviço no longo prazo
• Formato centrado em visualização de dados, sem análises ou explicações adicionais

[GN⁺]

Comentários no Hacker News

• Fiquei me perguntando se os dados anteriores a 2018 são realmente precisos
  Lembro que já havia várias interrupções antes disso
  Talvez tenha sido a partir desse ponto que começaram a usar o atual sistema de rastreamento de uptime

  • Os dados foram obtidos da página oficial de status
    Mas essa página parecia ser mais para marketing/comunicação do que para observabilidade

• Pessoalmente, acho esta página de status alternativa melhor
  Com o nome “The Missing GitHub Status Page”, ela mostra de forma consolidada a taxa de disponibilidade dos últimos 90 dias
  No momento está em 90,84%, um pouco melhor que os 90,00% de alguns dias atrás

  • A situação recente foi bem turbulenta
    A disponibilidade do GitHub Actions em fevereiro de 2026 está em 98%, ou seja, apenas um único '9'
    Na prática, parece que falhou em 1 ou 2 a cada 50 vezes (cerca de 2%)
  • Esse tipo de número agregado não parece um indicador muito razoável
    Por exemplo, quando a OpenAI cai e o CoPilot para de funcionar, será que isso deve contar como downtime do GitHub?
  • Na verdade, as duas páginas só mostram as mesmas estatísticas de formas diferentes
    Parece que o OP apresentou isso de um jeito que enfatiza os resultados após a aquisição pela Microsoft
  • Fazendo as contas, “90%” significa quase 5 semanas de downtime
    Brincadeiras à parte, o GitHub agora já merece esse nível de ‘férias remuneradas’

• Mostrar os dados sem marcar quando cada recurso foi introduzido é tendencioso
  Por exemplo, o GitHub Actions foi lançado em agosto de 2019, então é natural que não houvesse downtime antes disso

  • Em “Breakdown”, você pode clicar em “Actions” para ocultar esse item
  • Ao olhar a página de detalhes, a escala de cada serviço individual diminui, mas a tendência geral permanece a mesma
  • Pior ainda é que aparece como “100% uptime” até em períodos em que aquilo nem existia

• Eu também fiz esse mesmo gráfico com o Claude algumas semanas atrás
  Esperava ver uma queda brusca antes e depois da aquisição pela Microsoft, mas na prática já havia há muito tempo um padrão irregular de falhas
  A narrativa de que antes da aquisição era mais estável é interessante, mas naquela época não existiam produtos como Actions
  Para os serviços que já existiam (API, Git ops, Pages etc.), isso talvez possa ser explicado por melhorias na observabilidade

  • Parece que, depois do lançamento do Actions, começou um cenário de pesadelo em termos de operação e disponibilidade
    Depois disso, os problemas se espalharam para áreas antes estáveis, como Issues e PRs
  • Pessoalmente, acho que o GitHub Actions deveria simplesmente desaparecer
    O Git foi originalmente projetado para fazer uma coisa bem, e encher isso de funcionalidades desnecessárias foi um grande erro

• Se as pessoas estão procurando um motivo, este artigo do The New Stack pode servir de explicação

  • Concordo totalmente. As falhas do Azure da nossa equipe e as falhas do GitHub quase sempre acontecem ao mesmo tempo
    Já virou quase um meme
  • Ainda assim, acho difícil explicar mais de 6 anos de baixa disponibilidade só com esse motivo
    Eles deveriam ter testado bastante em um ambiente separado e migrado para o Azure em um período curto

• No momento, a função de merge de PR não está funcionando
  O status relacionado pode ser visto na página de incidente do GitHub Status

• Lembro de ver com frequência a antiga página de erro do unicórnio
  Acho que naquela época a página de status não era atualizada com frequência

  • O unicórnio parecia ser um erro exclusivo da interface web
    Serviços como a Git API também quebravam separadamente, e a página de status costumava refletir isso com atraso

• Agora parece que o histórico de downtime do GitHub está pior que o do meu servidor pessoal
  Isso mesmo eu reiniciando e parando serviços com frequência para fazer experimentos

  • E mesmo assim continuamos pagando
    Parece que acreditamos que o nível de QoS continua mantido apesar da queda de qualidade
  • Até meu pequeno VPS é mensuravelmente mais estável que o GitHub

• Não sou alguém que defende o GitHub, mas aquele gráfico está com o eixo distorcido
  Como ele amplia só a faixa abaixo de 99,5%, parece muito pior do que realmente é

  • Mas, se você começar do 0, não dá para ver a diferença entre um serviço bom e um ruim
    O SLA corporativo é 99,9%, e a parte inferior do gráfico mostra 5 vezes mais downtime do que isso
    Ou seja, não parece ruim; ele realmente é ruim
  • O gráfico não reflete o fator de carga (load)
    Também é preciso considerar que, antes da aquisição pela Microsoft, havia limite de apenas um repositório privado
  • Não há necessidade de desenhar um gráfico de uptime começando do 0
    Mostrar apenas a faixa dos 99% faz sentido
    Acho que escala logarítmica seria exagero

• Como publico sites com GitHub Pages, fui investigar separadamente a disponibilidade da hospedagem estática
  Segundo esta análise de blog, o GH Pages tem um desempenho bem bom nessa categoria
  Mas esse mérito provavelmente deveria ir para o CDN da Fastly