Red Squares mostra falhas do GitHub como contribuições
(red-squares.cian.lol)- Red Squares parodia o gráfico de contribuições de commits do GitHub e, em vez de quadrados verdes, mostra quadrados vermelhos para indicar falhas na plataforma GitHub.com
- Cada quadrado vermelho representa um dia em que o GitHub teve uma falha, e quanto mais escura a cor, mais tempo a falha durou naquele dia
- No último ano, o tempo total de indisponibilidade do GitHub foi de 32,5 dias
- Houve 167 dias com pelo menos 1 incidente
- O pior dia foi quinta-feira, 30 de abril de 2026, com 1,0 dia de indisponibilidade
1 comentários
Comentários do Hacker News
Toda vez que aparece um site-meme de vibe coding como esse, surgem comentários sem fim dizendo que a causa real não é a carga, e sim que a equipe do GitHub, a stack técnica, a Microsoft e a Azure são ruins
Se comparar a página pública de status do GitHub com a página do Enterprise Cloud, os números do lado Enterprise são bem melhores, e pessoalmente nem lembro quando foi a última vez que houve uma falha tão séria a ponto de me impedir de trabalhar
Se o problema não tivesse relação com carga, eu acharia que os mesmos problemas de disponibilidade deveriam aparecer também no produto Enterprise
Especialmente no caso de uma empresa com mais recursos do que vários países e com profissionais de tecnologia de nível mundial, criticar o sistema é totalmente válido
A stack técnica do GitHub realmente não é boa, e isso vem sendo defendido com bastante arrogância há muito tempo
A Azure é uma plataforma terrível e está sendo empurrada à força para a equipe, e também já vi postura defensiva em relação à escolha de banco de dados relacional e à reescrita do frontend
Não conseguir manter o site estável e, ainda assim, reescrever a UI e empurrar ferramentas de IA é perda de tempo
Não é um ataque a engenheiros individuais, e sim uma crítica às escolhas da gestão de um sistema que se tornou praticamente um monopólio por efeito de rede e que prioriza recursos novos ou agradar os donos em vez do produto principal
Como a página de status pode ser usada como prova contra a empresa, essa comparação em si tem pouco sentido
Na prática, muitas vezes algo é uma falha, mas na linguagem de marketing vira “degradação de desempenho”, e páginas de status operadas de forma independente são muito mais úteis
Não é todo dia, mas quase não me lembro da última vez em que passei uma semana no trabalho sem precisar contornar alguma falha
Na maioria dos casos ainda dá para continuar “trabalhando”, mas tarefas que teriam sido buildadas ou implantadas no mesmo tempo acabam atrasando se houver falha, então pessoalmente sou afetado pelo menos uma vez por semana
Ou então pelo menos deveria colocar um aviso enorme no topo dizendo “uso apenas para hobby”
Consigo responder em threads existentes, mas não criar novas, e isso também está na página de status
Não sei como isso passou, e é difícil entender por que continua assim há uma hora
Muito gentil da parte deles dizer que a correção ainda vai levar mais 3 ou 4 horas
Não me parece justo culpar o GitHub até por degradação de desempenho de modelos externos como Gemini 2.5 Pro, Grok Code Fast 1 in Copilot e Claude Opus 4
Parece ser um problema sobre o qual o GitHub não tem o que fazer
A gravidade some, e tudo acaba resumido como “falha do GitHub” ou em um gráfico de disponibilidade
Tenho reclamações sobre as grandes falhas recentes do GitHub, mas não gosto de ver cada vez mais sites caça-atenção e posts sociais que borram a linha entre pequenas degradações de serviço e indisponibilidade total do site para parecer mais dramático e conseguir recomendações, likes, karma e atenção
Parece que só queriam deixar o gráfico o mais vermelho possível
Operamos um serviço bem menor que o GitHub, mas mesmo assim mantemos caminhos alternativos com vários provedores e vários modelos
O fim de semana ainda é uma fronteira não explorada
Ainda há espaço para expandir
As falhas cobriam 62% dos dias úteis e 11% dos fins de semana, e o Claude era parecido, com 92,5% nos dias úteis e 97,8% nos fins de semana
De terça a quinta é a zona de risco, e domingo parece praticamente outro serviço
https://www.aakash.io/tech-chase/github-and-claude-are-down-...
Antes de tudo, fico na dúvida se esse gráfico está correto
Aparece “170 dias com pelo menos uma falha · pior dia: quinta-feira, 20 de novembro de 2025, 1,1 dia”, mas não entendo como o total de um único dia pode ser 1,1 dia
Mesmo passando o mouse nessa data, não aparece como o cálculo interno foi feito, e um item isolado mostra 1,3 hora
Em 19 de novembro aparece um item de falha de 1,3 dia, mas o total é mostrado como 8,1 horas
Nessa data, ela mostra 24 horas de falha leve
Este site parece somar o downtime de todos os serviços ao longo de um dia, e nesse caso o pior dia poderia chegar a 10 dias de downtime ao somar o downtime diário por categoria principal
1: https://mrshu.github.io/github-statuses/
Não verifiquei se realmente houve downtime naquele dia, mas assumindo que os números estejam corretos, 7,8 horas somadas a 1 dia dão aproximadamente 1,3 dia
A diferença entre a página oficial de status [0] e a página de status de terceiros [1] é grande demais
Se isso for tão diferente do uso real do produto, fico me perguntando como os termos de acordo de nível de serviço são legais
Gosto do GitHub e do serviço, mas toda vez que ele está quebrado de verdade e a página de status continua verde eu sinto algo gritando por dentro
[0] https://www.githubstatus.com/
[1] https://mrshu.github.io/github-statuses/
No lugar onde trabalhei mais recentemente, tivemos muitas falhas do GitHub que não foram registradas na página de status, e deixamos logs disso via busca no Slack
Depois disso, o pessoal de negócios discutiu com o responsável pela conta do GitHub e conseguiu algumas centenas de dólares em crédito
Mas reclamaram que essas poucas centenas de dólares não valiam o tempo investido, então a baixa disponibilidade do GitHub continua e nada acontece
Já a página de terceiros trata até falha ou problema em um modelo específico como problema do GitHub, então pode haver diferença em relação ao uso real
Nos fins de semana há muito menos falhas
Perfeito, porque eu também não pretendia trabalhar nessas horas
Essa ideia já existe faz tempo
Em janeiro eu fiz isso para dividir o uptime por categoria de falha
https://isgithubcooked.com
É engraçado como quase não haver downtime no fim de semana faz isso parecer bastante com o gráfico de contribuições