GitHub dejó de publicar su uptime agregado hace años. Un desarrollador la reconstruyó desde cero — y los números que revela explican el colapso de infraestructura de 2026 por tráfico de agentes de IA.
Hace unas semanas hablamos de cómo leer la página de status de Claude para entender la salud real de un servicio de IA. Hoy toca la contraparte: GitHub, la plataforma sobre la que corre casi todo el ecosistema de desarrollo de software — y que dejó de publicar sus números de uptime agregado hace años.
Por eso existe The Missing GitHub Status Page, un proyecto de Marek Šuppa que reconstruye el historial de disponibilidad de GitHub a partir del feed de Atom público de status, comparando snapshots archivados desde 2017. GitHub sigue publicando incidentes individuales, pero el resumen agregado de uptime desapareció de su página oficial — y ahí es donde entra este mirror independiente.
¿Por qué importa esto ahora?
Porque los números detrás de esa "página perdida" cuentan una historia muy concreta: GitHub está siendo golpeado por un volumen de tráfico que no fue diseñado para absorber, y la causa es un solo factor — agentes de IA escribiendo, commiteando y abriendo pull requests a escala de máquina, no de humano.
Según cifras confirmadas por el propio COO de GitHub, Kyle Daigle, la plataforma procesó alrededor de mil millones de commits en todo 2025. Para 2026, el ritmo llegó a 275 millones de commits por semana. Haz la cuenta: en poco menos de cuatro semanas, GitHub recibe hoy el mismo volumen de actividad que recibió en los doce meses de 2025 completos.
Ese salto no es gradual — es una pared. Y se nota:
- Las pull requests abiertas por agentes de IA pasaron de ~4 millones en septiembre 2025 a ~17 millones en marzo 2026.
- El cómputo de GitHub Actions pasó de 500 millones de minutos por semana en 2023, a 1,000 millones en 2025, a 2,100 millones de minutos en una sola semana a inicios de 2026.
- Claude Code por sí solo pasó de ~100,000 commits semanales a finales de septiembre 2025 a 2.6 millones por semana — un aumento de 25x en tres meses.
El resultado: incidentes en cascada
GitHub reportó nueve incidentes de disponibilidad solo en mayo de 2026, y terceros midieron su uptime real por debajo del estándar de "tres nueves" que la industria da por sentado. La respuesta de Microsoft fue migrar tráfico de GitHub hacia Azure — y cuando eso no bastó, empezar a apoyarse también en infraestructura de AWS, su competidor directo en la nube, solo para sostener la carga.
La causa raíz que reconoció el propio CTO de GitHub: crecimiento de carga acelerado, servicios fuertemente acoplados que propagan fallas locales, y falta de protección contra tráfico de cliente anómalo. En otras palabras: la infraestructura fue diseñada para el ritmo de desarrolladores humanos, y los agentes autónomos operan en un patrón completamente distinto — no más rápido, sino de otra naturaleza.
La lección para cualquier equipo técnico
Si tu producto o tu stack depende de GitHub (y casi todos dependemos), esto no es una curiosidad de infraestructura ajena — es una señal de hacia dónde va la carga de todo el ecosistema. Vale la pena:
- Monitorear tus propios pipelines de CI/CD por sensibilidad a picos de saturación de terceros.
- No asumir SLA de "tres nueves" como garantía cuando el proveedor mismo reconoce que no los está cumpliendo.
- Diseñar con degradación elegante — que tu sistema siga funcionando (aunque sea a medias) si GitHub, npm, o cualquier dependencia externa tiene una mala semana.
La próxima vez que veas una página de status "aburrida" con todo en verde, recuerda que detrás de ese verde hay una carrera armamentista de infraestructura contra el tráfico de IA — y que a veces, como en el caso de GitHub, el dato completo ni siquiera está publicado. Alguien tuvo que reconstruirlo.
¿Quieres que revisemos la resiliencia de tu stack ante estas dependencias? Escríbenos por WhatsApp →
Conversación