El 17 de agosto de 2026, GitHub — la plataforma donde vive el código de buena parte del software del mundo — estuvo 7 horas y 47 minutos caído. No fue un ataque, ni un virus, ni alguien que borró el archivo equivocado. Fue falta de capacidad: el tráfico marcó un nuevo pico y un componente crítico no lo acompañó.
Si tu empresa no escribe software, la noticia parece lejana. No lo es. Lo que pasó allí pasa, en menor escala, con el sistema de gestión que pagas, con el datáfono, con el servidor de correo y con tu tienda online. La pregunta que responde este texto es una sola: ¿qué hace tu empresa durante las horas en que el sistema del que depende no está?
Qué pasó con GitHub
La caída empezó a las 13:28 y terminó a las 21:15 (hora UTC), según el informe publicado por la propia empresa. Se cayeron el sitio, la autenticación, GitHub Actions, las APIs, los pull requests, las issues y Copilot. En el pico, cerca del 20% de las peticiones de web y API fallaban, y las descargas de archivos y contenido bruto llegaron al 50% de error.
Traducido para quien no es del área: durante casi ocho horas, buena parte de los equipos de tecnología del mundo no pudo publicar nada. Quien tenía una entrega marcada para ese día no entregó.
La causa no fue un ataque ni un fallo de código — fue el crecimiento
Esta es la parte que más importa a quien decide. El informe de GitHub apunta a saturación de red en los balanceadores de carga del centro de datos del centro de Estados Unidos, provocada por un nuevo pico de tráfico. No hubo cambio de código ni configuración equivocada: la demanda superó lo que la infraestructura aguantaba.
Los números explican el tamaño del problema. Desde abril, los commits mensuales en la plataforma saltaron de 1.400 millones a 2.900 millones. Los pull requests aprobados llegaron a unos 130 millones por mes y los repositorios nuevos, a 24 millones por mes. La empresa dice haber añadido más de 3 millones de núcleos de procesamiento y 120 petabytes de almacenamiento rápido, además de pasar a servir cerca del 58% de la carga por la infraestructura de Azure.
Es decir: el éxito del producto fue la causa de la caída. Es el tipo de riesgo que nadie pone en la hoja de cálculo, porque no parece un problema: parece una buena noticia. Vale para una plataforma global y vale para tu empresa el día en que la campaña funcione y el sitio reciba diez veces más gente de lo normal.
El detalle que más enseña: el reintento automático
Cuando un sistema falla, los programas que dependen de él suelen intentarlo de nuevo, solos. Parece razonable — y, hecho sin cuidado, es lo que convierte un fallo en una caída larga. En el caso de GitHub el informe es explícito: los errores dispararon un bucle de reintentos del lado de los clientes que aumentó el tráfico durante la recuperación y retrasó la vuelta de Copilot.
Fíjate en el orden: el reintento automático no causó la caída, pero estorbó la salida de ella. Es un detalle técnico con consecuencia práctica directa para cualquier empresa con integraciones — facturación, cobro, envío de mensajes, sincronización con marketplace. La pregunta para tu proveedor o para quien cuida tu sistema es: cuando la llamada falla, ¿lo intenta de nuevo al instante, y cuántas veces? La respuesta correcta es esperar un poco más en cada intento y rendirse después de algunos — no martillar.
Antes del plan B, la pregunta que casi nadie hace
La conversación sobre indisponibilidad casi siempre empieza mal, por la tecnología. Debería empezar por la cuenta: ¿cuánto cuesta una hora parado, para cada parte de tu negocio?
Para una tienda online es la facturación media de la hora, más los clientes que no vuelven. Para una clínica es la agenda del día. Para una industria puede ser casi nada durante unas horas — y catastrófico si pilla el cierre del mes. Sin ese número, cualquier discusión sobre redundancia se vuelve preferencia personal, y la decisión acaba tomándola el susto del último problema.
La conclusión suele incomodar: la mayor parte de los sistemas de una empresa no merece plan B. Dos o tres lo merecen, y es ahí donde debe ir el dinero.
Los cuatro niveles de plan B
Del más barato al más caro. Elige el nivel por el coste de la hora parada que acabas de calcular.
1. Aviso. Saber que se cayó antes de que te lo diga el cliente. Es el nivel más barato de todos y el más ignorado: una comprobación automática cada pocos minutos que envía un mensaje cuando el servicio no responde. Sin eso, tu tiempo de caída empieza a contar cuando alguien se queja.
2. Modo manual. El acuerdo escrito de cómo trabaja el equipo sin el sistema: anotar el pedido en papel, hacer foto de la comanda, registrar después. Cuesta una hoja y una conversación, y es lo que salva la operación en la mayoría de las caídas cortas.
3. Alternativa fría. Una segunda copia de lo que importa, que no dependa del proveedor principal: la lista de clientes exportada cada semana, las facturas guardadas fuera del sistema, el registro en un archivo que puedas abrir tú solo. No sustituye al sistema — evita que la caída se convierta en pérdida.
4. Redundancia caliente. Un segundo camino listo para asumir. Es el único nivel que de verdad elimina la parada, y es caro: se paga por capacidad que está ociosa casi todo el tiempo. Solo se justifica cuando la hora parada cuesta más que la suscripción del segundo camino.
Lo que aprendimos tirando nuestro propio sistema
Dos historias nuestras, porque la teoría de continuidad es fácil de escribir y difícil de practicar.
La primera: el 2 de agosto, nuestra plataforma de realidad aumentada estuvo caída unos cuatro minutos. La causa fue un comando mal escrito que vació un archivo del servidor. Lo que acortó la caída no fue ninguna tecnología sofisticada — fue haber guardado una copia del archivo antes de cambiarlo y tener el servicio configurado para reiniciarse solo cuando muere.
La segunda es peor, y es la que más enseña. Creamos un script que recoge los contactos enviados por el formulario del sitio y los manda por correo — y olvidamos programarlo. No se cayó nada. Ninguna pantalla de error, ninguna alarma, el sitio respondiendo con normalidad. Los contactos simplemente se quedaban parados en una cola, esperando un programa que nunca se ejecutaba.
El fallo que asusta es el que tumba el sitio. El que cuesta dinero es el silencioso. Por eso el nivel 1 de la lista de arriba no es "vigilar si el sitio está en pie", sino "vigilar si lo que da dinero está ocurriendo": el pedido está llegando, el correo está saliendo, el cobro se está emitiendo.
Cómo decidir, en cuatro preguntas
Lleva esto a la próxima conversación con quien cuida tu tecnología:
1. ¿Cuáles son los dos o tres sistemas sin los que la operación se para hoy? 2. ¿Cuánto cuesta una hora sin cada uno de ellos? 3. ¿Cómo me entero de que se cayó — y en cuánto tiempo? 4. ¿Existe un acuerdo escrito de cómo trabajar sin él, que alguien además del dueño haya leído?
Si la cuarta pregunta no tiene respuesta, es por ella por donde se empieza: es la más barata de las cuatro y la que más reduce el destrozo.
Cuando la respuesta pasa por un sistema hecho a medida — porque lo estándar no da abasto con tu proceso, o porque depender de un solo proveedor se volvió un riesgo demasiado grande —, de eso nos ocupamos nosotros: desarrollo de software a medida. Y si la duda sigue siendo entre contratar algo estándar o mandarlo hacer, escribimos sobre cómo decidir entre software a medida y sistema estándar.
Fuentes
Informe oficial de GitHub sobre la caída del 17 de agosto de 2026 ("The August 17 outage, and the work ahead"), publicado en el blog de la empresa. Los datos de duración, servicios afectados, tasa de error, volumen de commits y capacidad añadida vienen de ahí.
Preguntas frecuentes
¿Cuánto tiempo puede estar mi sistema caído sin perjuicio?
No existe un número universal — depende de lo que cuesta una hora parada en tu negocio. El camino es calcularlo por sistema: facturación media de la hora para una tienda, agenda del día para una clínica, riesgo del cierre de mes para una industria. Ese número es el que define cuánto merece la pena gastar para reducir la parada.
¿Copia de seguridad y plan B son lo mismo?
No. La copia de seguridad guarda los datos y sirve para que no pierdas lo que ya tenías. El plan B es cómo sigue la operación mientras el sistema no vuelve. Puedes tener una copia perfecta y aun así pasar ocho horas sin atender a nadie.
¿Qué es una página de estado y por qué importa?
Es la página donde el proveedor publica si su servicio funciona. Importa porque acorta el tiempo entre la caída y tu decisión: en vez de gastar media hora pensando que el problema es tuyo, confirmas en un minuto que es del proveedor y activas el modo manual.
¿Contratar un sistema estándar es más seguro que mandar hacer uno a medida?
Ni más ni menos — el riesgo cambia de sitio. En el estándar dependes de la capacidad y las prioridades del proveedor, y su caída es tu caída. En el hecho a medida controlas la infraestructura y el orden de las reparaciones, pero necesitas a alguien responsable de eso. La elección depende de cuál de los dos riesgos gestiona mejor tu empresa.
¿Cómo sé si mis integraciones reintentan las llamadas de forma equivocada?
Pregunta a quien cuida el sistema tres cosas: cuántas veces se repite una llamada que falla, si el intervalo entre intentos crece en cada uno, y si hay un límite tras el cual se rinde y registra el error. Reintento inmediato y sin límite es el patrón que convierte un fallo corto en una caída larga.
¿Merece la pena pagar por redundancia?
Solo cuando la hora parada cuesta más que el segundo camino ocioso. Para la mayoría de las pymes, los tres primeros niveles — aviso, modo manual y alternativa fría — resuelven la mayor parte del problema por una fracción del precio, y es ahí donde tiene sentido empezar.