El historial de tiempo de actividad de GitHub

• Página que visualiza el tiempo de actividad mensual de GitHub entre 2016 y 2026
  • Todos los datos se basan en registros recopilados de la página oficial de estado
• Estructura que permite ver por separado el promedio de disponibilidad (Average) y el desglose detallado de interrupciones (Breakdown)
• Dentro de la página se puede acceder directamente a la fuente de datos original (View source)
• Material de visualización que permite revisar de un vistazo la tendencia de estabilidad del servicio a largo plazo
• Formato centrado en la visualización de datos, sin análisis ni explicaciones adicionales

[GN⁺]

Comentarios de Hacker News

• Me preguntaba si los datos anteriores a 2018 eran realmente precisos
  Recuerdo que también hubo varias caídas antes
  Quizá fue a partir de ese momento que empezaron a usar el sistema actual de seguimiento de uptime

  • Los datos se tomaron de la página oficial de status
    Pero esta página parece haber sido más para marketing/comunicación que para observabilidad

• Personalmente, creo que esta página de estado alternativa es mejor
  Se llama “The Missing GitHub Status Page” y muestra de forma agregada el porcentaje de disponibilidad de los últimos 90 días
  Ahora está en 90.84%, un poco mejor que el 90.00% de hace unos días

  • La situación reciente ha estado bastante brava
    La disponibilidad de GitHub Actions en febrero de 2026 fue de 98%, o sea, nivel de un solo '9'
    En la práctica, se sintió como que 1 o 2 de cada 50 veces fallaba (alrededor de 2%)
  • Este tipo de métrica agregada no parece un indicador muy razonable
    Por ejemplo, si OpenAI se cae y CoPilot deja de funcionar, queda la duda de si eso debería contarse como downtime de GitHub
  • En realidad, las dos páginas solo muestran las mismas estadísticas de manera diferente
    Parece que el OP las presentó de una forma que resalta los resultados posteriores a la adquisición por Microsoft
  • El cálculo de “90% son casi 5 semanas de downtime” sí sale
    Es broma, pero GitHub ya se ganó unas ‘vacaciones pagadas’ de ese tamaño

• Mostrar los datos sin marcar el momento en que se introdujo cada función es tendencioso
  Por ejemplo, GitHub Actions se lanzó en agosto de 2019, así que es natural que antes de eso no tuviera downtime

  • Si haces clic en “Actions” dentro de “Breakdown”, puedes ocultar ese elemento
  • Si ves la página de detalle, la escala de cada servicio individual se reduce, pero la tendencia general es la misma
  • Peor aún, aparece como “100% uptime” incluso en periodos en los que ni siquiera existía

• Yo también hice el mismo gráfico hace unas semanas con Claude
  Esperaba una caída fuerte antes y después de la adquisición por Microsoft, pero en realidad ya venía desde hace mucho un patrón irregular de caídas
  La narrativa de que antes de la adquisición era más estable es interesante, pero en ese momento no existían productos como Actions
  En los servicios que sí existían (API, Git ops, Pages, etc.), más bien podría explicarse por mejoras en la observabilidad

  • Desde el lanzamiento de Actions, da la impresión de que empezó una situación de pesadilla en términos de operación y disponibilidad
    Después, los problemas se extendieron a áreas antes estables como Issues o PR
  • Personalmente, creo que GitHub Actions debería desaparecer
    Git fue diseñado originalmente como una herramienta para hacer bien una sola cosa, y pegarle encima un montón de funciones innecesarias fue un gran error

• Si la gente está buscando una razón, este artículo de The New Stack podría dar una explicación

  • Totalmente de acuerdo. Las caídas de Azure de nuestro equipo y las de GitHub ocurren casi al mismo tiempo
    Ya se volvió una especie de meme
  • Aun así, me cuesta creer que más de 6 años de baja disponibilidad se expliquen solo por eso
    Deberían haber probado lo suficiente en un entorno separado y migrado a Azure en un periodo corto

• Ahora mismo la función de merge de PR no está funcionando
  El estado relacionado se puede ver en la página de incidentes de GitHub Status

• Recuerdo que antes veía muy seguido la página de error del unicornio
  Supongo que en ese tiempo la página de estado no se actualizaba con frecuencia

  • Parece que el unicornio era un error solo de la web
    Servicios como la API de Git también podían fallar por separado, y la página de estado solía reflejarlo con retraso

• Ahora el historial de downtime de GitHub parece peor que el de mi servidor personal
  Y eso que yo reinicio seguido o detengo servicios por estar experimentando

  • Y aun así seguimos pagando
    Parece que creen que, aunque baje la calidad, se mantiene el nivel de QoS
  • Incluso mi VPS pequeño es mediblemente más estable que GitHub

• No soy alguien que defienda a GitHub, pero ese gráfico tiene el eje distorsionado
  Está ampliado solo por debajo de 99.5%, así que se ve mucho peor de lo que realmente es

  • Pero si lo dibujas desde 0, no se ve la diferencia entre un servicio bueno y uno malo
    El SLA empresarial es 99.9%, y la parte inferior del gráfico muestra 5 veces más downtime que eso
    O sea, no es que se vea mal: realmente está mal
  • El gráfico no refleja el factor de carga (load)
    También hay que considerar que antes de la adquisición por Microsoft los repositorios privados estaban limitados a uno
  • No hace falta dibujar un gráfico de uptime desde 0
    Mostrar solo el rango del 99% es razonable
    Incluso diría que una escala logarítmica sería excesiva

• Como despliego sitios web con GitHub Pages, investigué por separado la disponibilidad del hosting estático
  Según este análisis de blog, GH Pages sale bastante bien parado en ese rubro
  Aunque ese mérito probablemente se lo lleve el CDN de Fastly