Red Squares: muestra las caídas de GitHub como contribuciones
(red-squares.cian.lol)- Red Squares parodia el gráfico de contribuciones por commits de GitHub y, en lugar de cuadros verdes, muestra cuadros rojos para señalar las interrupciones de la plataforma GitHub.com
- Cada cuadro rojo representa un día en que GitHub sufrió una caída, y cuanto más intenso es el color, más tiempo duró la interrupción ese día
- En el último año, el tiempo total de inactividad de GitHub se calcula en 32.5 días
- Hubo 167 días con al menos 1 incidente
- El peor día fue el jueves 30 de abril de 2026, con 1.0 día de inactividad
1 comentarios
Comentarios de Hacker News
Cada vez que aparece uno de estos sitios meme de vibe coding, salen interminablemente comentarios diciendo que la causa real no es la carga, sino que el equipo de GitHub, su stack técnico, Microsoft y Azure son mediocres
Si comparas la página pública de estado de GitHub con la de Enterprise Cloud, los números de Enterprise son mucho mejores, y personalmente ni recuerdo cuándo fue la última vez que hubo una caída tan grave que me impidiera trabajar
Si el problema no tuviera relación con la carga, entonces ese mismo problema de disponibilidad también debería verse en el producto Enterprise
Especialmente cuando se trata de una empresa con más recursos que muchos países y con talento técnico de primer nivel mundial, es totalmente válido criticar el sistema
El stack técnico de GitHub sí es malo en la práctica, y lo han defendido con bastante arrogancia durante mucho tiempo
Azure es una plataforma terrible que le imponen a la fuerza al equipo, y también he visto una postura defensiva sobre la elección de la base de datos relacional o la reescritura del frontend
Reescribir la UI y empujar herramientas de IA cuando ni siquiera pueden mantener el sitio estable es una pérdida de tiempo
No se está atacando a ingenieros individuales, sino criticando las decisiones de la dirección de un sistema que se volvió prácticamente un monopolio por efectos de red y que prioriza funciones nuevas o satisfacer a sus dueños por encima del producto principal
Como la página de estado puede usarse como evidencia en contra de la empresa, la comparación en sí tiene poco sentido
En la práctica, muchas veces a una caída se le llama “degradación del rendimiento” en lenguaje de marketing, y una página de estado operada de forma independiente resulta mucho más útil
No pasa todos los días, pero casi no recuerdo una semana en la empresa en la que no hayamos tenido que rodear una caída
En la mayoría de los casos el “trabajo” puede continuar, pero si no hubiera fallas, tareas que se habrían compilado o desplegado en ese mismo tiempo se retrasan, así que personalmente me veo afectado al menos una vez por semana
O al menos debería poner arriba una advertencia grande de “solo para uso recreativo”
Puedo responder en hilos existentes, pero no crear uno nuevo, y también aparece en la página de estado
No sé cómo dejaron pasar algo así, y menos entiendo por qué sigue así después de una hora
Qué amables de avisar que la corrección todavía tardará de 3 a 4 horas
No me parece justo culpar a GitHub incluso por la degradación de rendimiento de modelos externos como Gemini 2.5 Pro, Grok Code Fast 1 in Copilot o Claude Opus 4
No creo que sea un problema sobre el que GitHub pueda hacer algo
Se borra la gravedad y todo se resume como “caídas de GitHub” o como un gráfico de disponibilidad
Tengo quejas sobre las grandes caídas recientes de GitHub, pero no me gusta ver cada vez más sitios y publicaciones hechas para llamar la atención que difuminan la línea entre pequeñas degradaciones de servicio y caídas de todo el sitio para hacerlo ver más dramático y conseguir recomendaciones, likes, karma y atención
Parece que solo querían poner el gráfico lo más rojo posible
Nosotros operamos un servicio mucho más pequeño que GitHub, pero tenemos rutas alternativas preparadas con varios proveedores y varios modelos
El fin de semana sigue siendo una frontera aún no explorada
Todavía hay margen para expandirse
Las incidencias abarcaron el 62% de los días de semana y el 11% de los fines de semana, y Claude mostraba algo similar: 92.5% entre semana y 97.8% en fin de semana
De martes a jueves es la zona de peligro, y el domingo de verdad parece otro servicio
https://www.aakash.io/tech-chase/github-and-claude-are-down-...
Para empezar, dudo que este gráfico sea correcto
Dice “170 días con al menos una incidencia · peor día jueves 20 de noviembre de 2025, 1.1 días”, y no entiendo cómo es posible que el total de un solo día sea 1.1 días
Incluso al pasar el cursor sobre esa fecha no se ve cómo lo calcula internamente, y un elemento individual aparece como 1.3 horas
El 19 de noviembre sí hay un elemento de 1.3 días de caída, pero el total mostrado es de 8.1 horas
En esa fecha aparece como 24 horas de incidencias menores
Este sitio parece sumar el tiempo caído de todos los servicios durante un día, y si es así, el peor día podría llegar hasta 10 días de caída al sumar el tiempo caído diario de cada categoría principal
1: https://mrshu.github.io/github-statuses/
No verifiqué si realmente hubo caída ese día, pero si asumimos que los números son correctos, 7.8 horas más 1 día da aproximadamente 1.3 días
La diferencia entre la página oficial de estado [0] y la página de estado de terceros [1] es demasiado grande
Si de verdad difiere tanto de cómo se usa el producto, me pregunto cómo son legales los términos del acuerdo de nivel de servicio
Me gusta GitHub y me gusta el servicio, pero cada vez que está roto en la práctica y la página de estado sigue en verde, algo me grita por dentro
[0] https://www.githubstatus.com/
[1] https://mrshu.github.io/github-statuses/
En el lugar donde trabajé recientemente sufrimos muchas caídas de GitHub que no quedaron registradas en la página de estado, y lo fuimos dejando documentado con búsquedas en Slack
Después, el equipo de negocio discutió con el ejecutivo de cuenta de GitHub y consiguió unos cientos de dólares en créditos
Pero se quejaron de que esos cientos de dólares no valían el tiempo invertido, y por eso la baja disponibilidad de GitHub sigue igual y no pasa nada
En cambio, la página de terceros considera como problema de GitHub incluso la caída o falla de un solo modelo específico, así que puede diferir del uso real
Los fines de semana hay muchas menos caídas
Como de todos modos no pensaba trabajar en ese momento, perfecto
Esta idea existe desde hace tiempo
En enero hice esto para desglosar la disponibilidad por categoría de incidencia
https://isgithubcooked.com
Da risa que casi no haya downtime los fines de semana porque se parece bastante al gráfico de contribuciones