GitHub: 99.55% uptime en Pull Requests vs 99.98% en API a 90 días

⏱️ Lectura: 11 min

El status page de GitHub muestra algo que pocas plataformas exponen con tanto detalle: el porcentaje exacto de tiempo que cada servicio estuvo operativo durante los últimos 90 días. Y los números no son uniformes.

📑 En este artículo

1. TL;DR
2. Qué pasó: GitHub expone su uptime real servicio por servicio
3. Contexto e historia: la era de la transparencia en status pages
4. Datos y cifras: el desglose servicio por servicio
5. Impacto y análisis: por qué Pull Requests sufre más
6. Qué sigue: hacia status pages predictivas
7. Preguntas frecuentes
   1. ¿Qué significa exactamente 99.55% de uptime?
   2. ¿Por qué Pull Requests es el componente menos confiable?
   3. ¿Hay diferencias entre regiones?
   4. ¿Cómo puedo monitorear el status de GitHub desde mi aplicación?
   5. ¿Qué hago si Pull Requests está degradado durante un release crítico?
   6. ¿Por qué la API tiene mejor uptime que Pull Requests?
8. Referencias

Mientras la API de GitHub y Packages reportan 99.98% de uptime — apenas 26 minutos de interrupción acumulada en 90 días —, Pull Requests aparece al 99.55%, lo que equivale a casi 10 horas de degradación. Este desglose público, raro entre proveedores de su tamaño, ofrece una lección sobre qué partes de una plataforma de desarrollo son intrínsecamente más frágiles y por qué el uptime de GitHub no se puede contar como un solo número.

TL;DR

• GitHub publica métricas de uptime a 90 días para 8 servicios desde githubstatus.com.
• Pull Requests reporta el uptime más bajo del conjunto: 99.55% (≈ 9.7 horas de degradación en 90 días).
• API Requests y Packages lideran con 99.98% (≈ 26 minutos de interrupción acumulada).
• Git Operations, el corazón del producto, está al 99.83% (≈ 3.7 horas).
• Actions y Webhooks rondan el 99.66-99.73%, en línea con servicios asíncronos complejos.
• GitHub ofrece status pages regionales para Enterprise Cloud: au, eu, jp y us.
• El nivel de granularidad es inusual: la mayoría de plataformas SaaS solo muestran ‘operational’ o ‘degraded’ sin porcentajes.
• La API JSON pública /api/v2/status.json permite integrar el estado a dashboards internos.

Qué pasó: GitHub expone su uptime real servicio por servicio

El sitio githubstatus.com muestra de forma permanente las métricas de disponibilidad de los 8 componentes principales del producto. La página no oculta los puntos débiles: el servicio de Pull Requests, uno de los más críticos para el flujo de trabajo de desarrollo, aparece con 99.55% de uptime en los últimos 90 días. Convertido a tiempo, son aproximadamente 583 minutos de degradación, cerca de 9 horas y 43 minutos.

El resto del desglose es igual de revelador. Webhooks, el sistema que dispara notificaciones a sistemas externos cuando ocurren eventos en repositorios, reporta 99.73%. Actions, la plataforma de CI/CD integrada, está al 99.66%. En el otro extremo, las llamadas a la API REST y GraphQL acumulan 99.98%, junto con Packages, el registro de paquetes (npm, Docker, Maven, NuGet, RubyGems).

Este nivel de granularidad — un porcentaje específico por componente, no solo un estado binario ‘up/down’ — es algo que muy pocas plataformas SaaS de su escala ofrecen públicamente. Cloudflare, Stripe y Twilio publican incidentes pero raramente porcentajes consolidados visibles en la portada.

Contexto e historia: la era de la transparencia en status pages

Hace una década, exponer públicamente las métricas de uptime de una plataforma era visto como un riesgo reputacional. Hoy, después de incidentes virales como el outage de AWS S3 en 2017 (que tumbó medio internet por 4 horas) y la caída global de Facebook en 2021, la transparencia se volvió un diferenciador competitivo.

El modelo de status page que GitHub usa proviene de Atlassian Statuspage, la herramienta SaaS dominante en este nicho. Cloudflare, Stripe, Twilio, Slack y la mayoría de proveedores cloud usan variantes del mismo formato. Sin embargo, no todos publican porcentajes de uptime: muchos se quedan en ‘operational’ sin números, o publican métricas globales agregadas que ocultan la variabilidad por servicio.

GitHub ha sufrido incidentes notorios. En 2018, una falla en la red interna durante una migración generó más de 24 horas de problemas intermitentes que afectaron a equipos en todo el mundo. En 2020, un outage de Actions dejó miles de pipelines de CI/CD bloqueados durante varias horas. Más recientemente, una serie de incidentes en Pull Requests degradó el merge queue de forma intermitente. Cada uno se documentó con post-mortems en el blog de ingeniería, una práctica que también es parte de la cultura de transparencia.

📌 Nota: El ‘uptime’ en una status page no siempre captura toda la realidad del usuario. Una API puede estar ‘operational’ pero responder con latencia alta o errores intermitentes en una región específica. Las métricas binarias suavizan la experiencia real.

Datos y cifras: el desglose servicio por servicio

Convirtamos los porcentajes en algo más tangible. En 90 días hay 129.600 minutos. Cada centésima de porcentaje equivale a 12.96 minutos de disponibilidad o indisponibilidad. Así se traduce el uptime de GitHub en horas reales:

• Git Operations: 99.83% — ~220 minutos (3.7 horas) de interrupción. El servicio que maneja git push, git pull, clones y fetches. Es el más fundamental.
• Webhooks: 99.73% — ~350 minutos (5.8 horas). Notificaciones a sistemas externos. La asincronía y la cola pueden acumular retrasos visibles.
• API Requests: 99.98% — ~26 minutos. Lo más alto del conjunto. Llamadas a REST API y GraphQL.
• Issues: 99.86% — ~181 minutos (3 horas). El sistema de tracking de bugs y feature requests.
• Pull Requests: 99.55% — ~583 minutos (9.7 horas). El servicio menos confiable del conjunto.
• Actions: 99.66% — ~440 minutos (7.3 horas). CI/CD con workers efímeros y orquestación compleja.
• Packages: 99.98% — ~26 minutos. Registro de paquetes para npm, Docker, Maven, NuGet y otros.
• Pages: operacional — la métrica visible en el sitio en vivo, alineada con el resto del conjunto.

Para ponerlo en perspectiva, los SLAs típicos del mercado para servicios cloud ‘tres nueves’ (99.9%) permiten hasta 129 minutos (2 horas 9 minutos) de downtime mensual. GitHub Pull Requests, con 99.55%, está por debajo de ese umbral en un período de tres meses.

graph TB
    A["Git Operations 99.83%"] --> B["Pull Requests 99.55%"]
    A --> C["Issues 99.86%"]
    D["API 99.98%"] --> B
    D --> C
    B --> E["Actions 99.66%"]
    E --> F["Webhooks 99.73%"]
    F --> G["Sistemas externos"]
    D --> H["Packages 99.98%"]

Impacto y análisis: por qué Pull Requests sufre más

El hecho de que Pull Requests sea el componente con menor uptime no es casual. Detrás de un PR hay una orquestación compleja: el merge queue, la sincronización con CI checks, el cálculo de diffs entre ramas que pueden tener miles de commits, los checks de protected branches, las reviews automáticas con CODEOWNERS, la integración con Actions, las notificaciones a reviewers, el syncing con linked issues y el cómputo de ‘ready to merge’.

Cada uno de esos subsistemas es un punto de falla. Cuando un solo bus de eventos se atrasa, todo el flujo de PR se degrada aunque la página técnicamente cargue. Para un usuario, ver el botón de merge en gris durante una hora ya cuenta como interrupción, aunque GitHub la clasifique como ‘incident’ y no como ‘outage’ completo.

API Requests, en cambio, es la capa más cercana al hierro: una vez que el request llega al frontend de la API, la lógica es relativamente directa. Por eso 99.98% es alcanzable. Packages tiene una arquitectura similar — son endpoints de descarga con caché agresivo y CDN.

💭 Clave: La complejidad de un servicio es inversamente proporcional a su uptime esperado. Cuantos más subsistemas dependen entre sí, más probable es que uno falle y arrastre la métrica global.

Actions, con 99.66%, vive la misma paradoja. Cada workflow lanza un VM efímero, descarga el código, instala dependencias, ejecuta jobs, sube artefactos. Cualquier hop puede fallar. GitHub corre esto a escala de millones de jobs por día, y el porcentaje refleja la realidad de un sistema distribuido masivo.

Para equipos de desarrollo, el análisis práctico es: si tu pipeline crítico depende de Pull Requests + Actions + Webhooks simultáneamente, tu uptime efectivo es el producto: 0.9955 × 0.9966 × 0.9973 = 0.9894, o 98.94%. Eso son 23 horas de degradación posible en 90 días, más de un día completo. Si tu equipo en LATAM hace releases nocturnos para evitar la franja horaria de mayor carga en EE.UU., la probabilidad de cruzarse con un incidente menor es real.

Qué sigue: hacia status pages predictivas

La tendencia en SRE va hacia exponer no solo uptime histórico sino también señales en tiempo real: latencia p95/p99, tasa de errores 5xx, rendimiento. Cloudflare Radar y la API de status de OpenAI ya empiezan a hacerlo. Eventualmente, los status pages dejarán de ser snapshots de ‘operational/degraded’ para volverse dashboards reales con métricas accionables.

Para los desarrolladores en LATAM que dependen de GitHub para su flujo diario, la lección es operativa: integrá la API de Status de GitHub a tus sistemas internos. El endpoint https://www.githubstatus.com/api/v2/status.json devuelve el estado actual en formato JSON. Podés montar un dashboard interno o disparar alertas cuando un componente esté degradado.

Ejemplo en Python:

import requests

resp = requests.get("https://www.githubstatus.com/api/v2/status.json", timeout=5)
data = resp.json()
print(data["status"]["description"])  # "All Systems Operational"
print(data["status"]["indicator"])    # "none", "minor", "major", "critical"

Ejemplo en Node.js (Windows, macOS y Linux con Node 18+):

const res = await fetch("https://www.githubstatus.com/api/v2/components.json");
const { components } = await res.json();

for (const c of components) {
  console.log(`${c.name}: ${c.status}`);
}

Ejemplo en curl desde cualquier shell:

curl -s https://www.githubstatus.com/api/v2/components.json | jq '.components[] | {name, status}'

Esto te da el estado por componente individual. Si Pull Requests aparece como ‘degraded_performance’, podés alertar a tu equipo antes de que noten la degradación al intentar mergear. Para entornos en Argentina, Chile, Colombia o México donde la latencia hacia los datacenters de GitHub en EE.UU. puede sumar 100-200ms extra, monitorear el status reduce la confusión entre ‘es mi internet’ y ‘es GitHub’.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué significa exactamente 99.55% de uptime?

Significa que durante 90 días el servicio estuvo disponible 99.55% del tiempo. El restante 0.45% — aproximadamente 583 minutos o 9 horas 43 minutos — fue clasificado como degradado o caído por el sistema de monitoreo interno de GitHub. No todo ese tiempo fue una caída total: la mayoría suelen ser degradaciones parciales.

¿Por qué Pull Requests es el componente menos confiable?

Pull Requests integra varios subsistemas: cálculo de diffs entre ramas, merge queue, status checks de CI/CD, CODEOWNERS, reviewers, linked issues, integración con Actions y notificaciones. Un fallo en cualquiera de ellos degrada la experiencia, aunque la página técnicamente cargue. La complejidad es el enemigo del uptime.

¿Hay diferencias entre regiones?

Sí. GitHub Enterprise Cloud ofrece status pages regionales: au.githubstatus.com (Australia), eu.githubstatus.com (Europa), jp.githubstatus.com (Japón) y us.githubstatus.com (Estados Unidos). Un incidente puede afectar solo una región mientras las demás permanecen operativas.

¿Cómo puedo monitorear el status de GitHub desde mi aplicación?

GitHub expone una API JSON pública: https://www.githubstatus.com/api/v2/status.json para el estado global y /api/v2/components.json para el desglose por servicio. También hay feeds RSS y Atom para suscribirse a incidentes sin polling activo.

¿Qué hago si Pull Requests está degradado durante un release crítico?

Plan B: usar git directo desde la línea de comandos para el merge, evitando la UI web. Para CI/CD, considerar mover workflows críticos a runners self-hosted o tener un proveedor alterno (CircleCI, Buildkite) preconfigurado. La diversificación reduce el blast radius de cualquier proveedor único.

¿Por qué la API tiene mejor uptime que Pull Requests?

La API REST/GraphQL es una capa más simple: recibe requests y los enruta a la base de datos. Pull Requests es una composición de múltiples APIs y servicios internos. Cuantos más componentes en la ruta crítica, mayor la probabilidad de fallo acumulado. Es el principio multiplicativo aplicado a sistemas distribuidos.

Referencias

• GitHub Status (githubstatus.com) — Status page oficial con métricas de uptime a 90 días por componente.
• GitHub Status API — Endpoint JSON público con el estado actual de todos los servicios.
• GitHub Enterprise Cloud EU Status — Status page regional para Europa, parte de la red global de monitoreo.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.