El 17 de agosto de 2026 GitHub estuvo caído siete horas y cuarenta y siete minutos. Se fueron con él la autenticación, Actions, la API, los pull requests, las issues y Copilot, y muchísimos equipos pasaron parte de esa tarde averiguando si lo que se había roto era su propia build.
Esa pregunta - ¿somos nosotros o son ellos? - conviene poder responderla en dos minutos y no en dos horas, y las pruebas que la responden desaparecen en cuanto termina el incidente.
Las pruebas, en el orden en que sirven
Qué host está fallando. Abre la pestaña Red y mira adónde van las peticiones que fallan. Un 500 de tu propio dominio es tuyo. Un 503 de una API que no gestionas tú no lo es, por mucho que parezca que la rota es tu funcionalidad. Suena obvio y es el paso que la gente se salta, porque el síntoma aparece en tu interfaz y la interfaz es lo que están mirando.
Qué dice el código de estado. Un 401 o un 403 durante el incidente de autenticación de otro no es un fallo de permisos en tu código, y es el que más veces se archiva como tal. Un 429 es un límite de peticiones y puede ser consecuencia de tus propios reintentos. Un timeout sin respuesta ninguna apunta hacia fuera más a menudo que hacia dentro.
Si coincide con tu despliegue. La primera pregunta en cualquier canal de incidentes es qué ha cambiado. Si tu última release fue tres horas antes de que empezaran los síntomas, eso vale la pena decirlo en el primer mensaje y no en el quinto.
Qué dice su página de estado, consultada en segundo lugar y no en primero. Las páginas de estado las actualiza gente que está ocupada apagando el fuego, y van unos minutos por detrás del fallo. Tu propia pestaña Red se entera antes que su página de estado.
La trampa: tus reintentos pueden empeorarlo
La parte del relato de GitHub que merece leerse dos veces es lo que pasó durante la recuperación. Su propio postmortem dice:
Los errores en esos servicios provocaron un bucle de reintentos en el cliente que aumentó el tráfico durante la recuperación. Tuvimos que mitigar ese comportamiento antes de poder restablecer el tráfico con seguridad.
Es decir: los clientes que más se esforzaban por entrar formaban parte de lo que mantenía la puerta cerrada. La lista de medidas de GitHub nombra el arreglo en términos generales - “límites de reintentos coherentes, presupuestos de reintentos y timeouts variables en las interacciones entre servicios, para evitar tormentas de reintentos y carga en cascada” - y esa es una frase que conviene poner al lado de tu propio código.
Una lógica de reintentos escrita para una petición fallida suelta se comporta de otra manera cuando falla cada petición. Sin presupuesto, sin backoff y sin jitter, cien instancias reintentando todas con el mismo calendario se convierten en una prueba de carga sincronizada apuntada a un servicio que ya está sufriendo.
También vale la pena saber que ninguno de los dos incidentes de GitHub en agosto vino de un cambio de código o de configuración. Los dos fueron fallos de capacidad. El instinto de buscar el despliegue que lo provocó suele acertar y aquí se equivocaba.
Captúralo mientras está roto
Una caída es el único tipo de defecto que se repara solo, y las pruebas se van con él. Dos horas después la petición que devolvía un 503 devuelve un 200, y el ticket dice “fallo intermitente, no se reproduce” durante el resto de su vida.
Lo que quieres, tomado durante el incidente: las peticiones que fallan con sus códigos de estado y sus tiempos, la salida de la consola y la hora a la que ocurrió cada una.
Session Replay
Extensión gratuita de Chrome. Un clic en la página que se está portando mal captura la captura de pantalla, la consola y el registro de red, y te devuelve un enlace para pegar en el ticket.
El registro de red incluye un archivo HAR, que es justo el artefacto que el soporte del otro te va a pedir de todas formas. Sanéalo antes de mandarlo: un HAR guardado con contenido lleva cookies de sesión y cabeceras de autorización, y es lo único de este flujo de trabajo que ya ha provocado una filtración en otra empresa.
Escribirlo de forma que no se archive mal
Un informe de incidente y un informe de error son documentos distintos, y confundirlos le cuesta la mañana a un desarrollador.
Si el fallo es de otro, dilo en el título, y di qué significa para ti: qué funcionalidad está afectada, si hay un apaño y qué estás esperando. “Checkout fallando - el proveedor de pagos devuelve 503 desde las 14:10, sin apaño posible, su página de estado lo reconoce” es un informe completo. Nadie necesita reproducirlo, y nadie debería intentarlo.
Si puede que sea tuyo, es un informe de error corriente y quiere las cosas de siempre: qué esperabas, qué pasó, el entorno y las pruebas. Nuestra guía para escribir uno tiene la forma, y los diez errores más comunes cubren lo que suele faltar.
Y si de verdad todavía no lo sabes, escribe eso. “No está claro si es nuestro - las peticiones que fallan van a un host externo, pero nuestra release salió a las 13:30” es más útil que una suposición segura de sí misma en cualquiera de las dos direcciones.
Después
Dos preguntas que merece la pena hacerse cuando el incidente ha terminado, mientras la gente aún se acuerda.
¿Cuánto tardamos en saber que no éramos nosotros? Si la respuesta es una hora, el arreglo suele estar en la visibilidad y no en la resiliencia: algún sitio donde mirar que enseñe qué hosts están fallando.
¿Nuestros reintentos ayudaron o estorbaron? GitHub tuvo que mitigar el comportamiento de los clientes antes de poder restablecer el tráfico. Tus clientes son el comportamiento de cliente de otra persona.
Fuentes: el relato que hace GitHub del incidente está en The August 17 outage, and the work ahead, y es inusualmente concreto sobre lo que salió mal. Publicado en su honor, y citado aquí porque un postmortem que nombra las tormentas de reintentos es más útil que cualquier consejo sobre ellas.