78 minutos de error, cinco días de caída: lo que CrowdStrike y Delta enseñan sobre recuperarse

El error duró 78 minutos y fue de otra empresa. La recuperación duró de uno a cinco días, y esa sí fue de cada quien. El 19 de julio de 2024, la misma falla le pegó a varias aerolíneas de Estados Unidos. Para el lunes siguiente, la mayoría operaba casi con normalidad. Delta Air Lines canceló cerca de 7,000 vuelos en cinco días.

¿Por qué la misma falla le costó un fin de semana a unas y cinco días a otra? Esa pregunta sigue abierta, y Delta y CrowdStrike la pelean en tribunales. Delta dice que dependía más que nadie de la tecnología afectada; CrowdStrike, que lo que alargó la recuperación fueron la respuesta y la infraestructura de la propia Delta. Este artículo no resuelve ese pleito. Lo que el caso sí enseña a cualquier empresa, gane quien gane, es que cuánto tarda en volver se decide en buena parte antes de la falla, con lo que dejó preparado.

Esta es la historia documentada, hora por hora, con lo que dice cada parte: Delta y CrowdStrike, que se demandaron mutuamente, y Microsoft, que respondió por carta. Al final, lo que enseña para cualquier empresa que dependa de sus sistemas, que hoy son casi todas.

Jueves, 10:09 de la noche en la Ciudad de México

CrowdStrike vende un programa de seguridad llamado Falcon. Su sensor se instala en las computadoras y servidores que la empresa cliente quiere proteger y vigila lo que pasa dentro del sistema operativo para detectar ataques. Para reconocer técnicas nuevas, recibe con frecuencia pequeñas actualizaciones de contenido: no cambian el programa, solo le enseñan qué buscar.

El viernes 19 de julio de 2024, a las 04:09 en hora universal (UTC), CrowdStrike publicó una de esas actualizaciones para los equipos con Windows [1]. En la costa este de Estados Unidos eran las 12:09 de la madrugada [8]. En la Ciudad de México, las 10:09 de la noche del jueves.

La actualización traía dos plantillas nuevas para vigilar cómo se comunican los programas entre sí dentro de Windows. Una de ellas pedía revisar un dato que nadie había revisado antes. El análisis de causa raíz que CrowdStrike publicó el 6 de agosto lo explica así: ese tipo de plantilla, creado en febrero de 2024, definía 21 campos de entrada, pero el código que la ejecutaba solo le entregaba 20 [2]. Durante meses no pasó nada, porque las pruebas y las plantillas anteriores usaban un comodín en el campo 21: «cualquier valor sirve». La del 19 de julio fue la primera que de verdad comparaba contra ese campo [2].

El programa intentó leer el dato número 21 fuera de la memoria reservada para los 20 que recibía, y Windows se detuvo [1][2]. La herramienta que debía validar el contenido antes de enviarlo tenía su propio error y lo dejó pasar [1]. Lo que siguió lo vieron millones de personas: la pantalla azul.

A las 05:27 UTC, 78 minutos después, CrowdStrike retiró la actualización [1]. Los equipos que se conectaron después ya no la recibieron. Pero los que sí la recibieron no podían descargar la versión corregida, porque se caían antes de terminar de arrancar.

Viernes: 8.5 millones de pantallas azules

Al día siguiente, Microsoft estimó el alcance: 8.5 millones de dispositivos con Windows, «menos del uno por ciento de todas las máquinas Windows» [3]. Era poco en porcentaje y enorme en consecuencias. Microsoft lo explicó así: el impacto económico y social reflejaba que CrowdStrike lo usan empresas que operan muchos servicios críticos [3]. Las aerolíneas estaban entre ellas.

El arreglo existía desde la madrugada. Lo difícil era aplicarlo. Las instrucciones de Microsoft pedían, equipo por equipo, arrancar en modo seguro desde la pantalla de recuperación, entrar a la carpeta de CrowdStrike, borrar los archivos C-00000291*.sys y reiniciar [4]. Y había un detalle que convirtió minutos en horas: en los equipos con el disco cifrado con BitLocker, la herramienta de cifrado de Windows, ese arranque podía pedir la clave de recuperación [4][5]. Una clave larga, distinta para cada equipo, que alguien tenía que haber guardado en un lugar al que se pudiera llegar mientras todo lo demás estaba caído.

En otras palabras, en muchos equipos la reparación exigía que alguien estuviera frente a la máquina. Microsoft publicó después una herramienta en memoria USB para automatizar parte del arreglo, pero también había que conectarla equipo por equipo [4]. Delta alegaría en su demanda que, en su caso, los equipos «tuvieron que remediarse manualmente uno a la vez y no podían arreglarse a distancia» [9]. Su director general, Ed Bastian, dijo a CNBC que la aerolínea tuvo que reiniciar a mano 40,000 servidores [10].

CrowdStrike reportó una recuperación rápida en su base de clientes: más de 97 % de los sensores de Windows estaban de nuevo en línea el 24 de julio y alrededor de 99 % el 29 de julio, comparados con la semana anterior [5][2]. Las cifras generales se veían bien. Pero el promedio escondía a quien no se estaba levantando.

Sábado y domingo: unas se levantan, otra no

Las aerolíneas viven de un rompecabezas que se arma cada día: qué avión va a qué ruta, qué piloto y qué tripulación van en cada vuelo, y si cada persona cumple con las horas de descanso que exige la ley. Si el sistema que arma ese rompecabezas se detiene, los aviones pueden estar listos y aun así no despegar, porque nadie sabe con certeza quién está dónde.

Varias aerolíneas afectadas cancelaron vuelos el viernes. Lo que importa es lo que pasó después. Según el recuento de la agencia AP del lunes 22 de julio, United, la segunda más golpeada, había cancelado casi 1,500 vuelos desde el viernes, pero ese lunes, a media mañana, solo llevaba 17. American, Spirit, Frontier y Allegiant estaban casi en la normalidad. Southwest y Alaska, que no usan CrowdStrike, tuvieron pocas cancelaciones [11].

Delta, en cambio, llevaba más de 5,500 vuelos cancelados desde el viernes, y el lunes canceló al menos 700 más. Ese día, Delta y sus aerolíneas regionales sumaban cerca de dos tercios de todas las cancelaciones del mundo, «incluidas casi todas las de Estados Unidos» [11].

Lunes: el sistema que no alcanzaba a ponerse al corriente

¿Qué estaba fallando, si las computadoras ya se estaban reparando? Delta lo explicó en esos días con sus propias palabras.

Bastian escribió a sus clientes que una de sus herramientas de seguimiento de tripulaciones había quedado afectada y no podía procesar el enorme volumen de cambios que provocó el apagón. Con aviones llenos en pleno verano, arriba de 90 % de ocupación, eso iba «limitando nuestras capacidades de reacomodo» [11]. A sus empleados les dijo que faltaba «otro par de días» para que «lo peor quede claramente atrás» [11].

El director de sistemas de Delta, Rahul Samant, fue más preciso. Según AP, dijo que las dos aplicaciones más difíciles de volver a levantar fueron la que administra el tráfico en el aeropuerto de Atlanta, su principal centro de operaciones, y la que asigna pilotos y sobrecargos a los vuelos. Esta última ya estaba corriendo, pero «tenemos que ponernos al corriente»; y, según AP, Samant dijo que seguían surgiendo problemas nuevos [11].

Ahí está el corazón del caso. Las computadoras se pueden reparar una por una. Pero un sistema que coordina a miles de personas no vuelve a la normalidad solo por encenderse: tiene que absorber todos los cambios acumulados mientras estuvo caído, y cada vuelo cancelado genera más cambios. Es una fila que crece mientras uno intenta vaciarla.

Martes: llega el regulador

El martes 23 de julio, el Departamento de Transporte de Estados Unidos (DOT) abrió una investigación a Delta. Según AP, la dependencia dijo que la abrió tras ver las interrupciones generalizadas y continuas en los vuelos de Delta «y reportes de fallas preocupantes de servicio al cliente» [12]. El secretario de Transporte, Pete Buttigieg, ya había hablado con Bastian y dijo que su dependencia había recibido «cientos de quejas» [11].

El miércoles 24, a las 7:45 de la mañana, Bastian publicó una nueva carta a clientes: las cancelaciones y demoras del martes habían bajado 50 % frente al lunes, esperaba cancelaciones mínimas el miércoles y un jueves normal. Ofreció millas y vales de viaje «como un gesto más de disculpa» [13].

Para el 31 de julio, Bastian le dijo a CNBC que en los siete días anteriores Delta había tenido menos de 100 cancelaciones sobre más de 30,000 vuelos [10]. La operación estaba de vuelta. El costo apenas empezaba a contarse.

La cuenta

En su reporte a la autoridad bursátil del 8 de agosto, Delta puso las cifras: alrededor de 7,000 cancelaciones en cinco días [6]. Un impacto directo en ingresos de 380 millones de dólares, sobre todo por reembolsos y compensaciones en efectivo y en millas, y 170 millones de gasto adicional, principalmente reembolsos de gastos a clientes y costos de tripulación. A cambio, por los vuelos que no volaron, gastó unos 50 millones menos en combustible [6]. Neto, alrededor de 500 millones de dólares.

«Una interrupción operativa de esta duración y magnitud es inaceptable, y nuestros clientes y empleados merecen algo mejor», dijo Bastian en ese mismo reporte [6]. Las personas afectadas fueron más de un millón, según la demanda de Delta [9]; 1.3 millones, según Reuters [7].

Tres versiones de la misma caída

A partir de aquí, la historia se vuelve disputa. Conviene leerla como lo que es: tres partes con abogados, cada una contando su versión, pero un solo pleito, de dos partes. Delta y CrowdStrike se demandaron mutuamente el mismo día, cada una en una corte distinta. Microsoft contestó por carta, y en esas demandas no figura como parte. Lo que sigue está tomado de sus propias cartas y demandas.

La versión de Delta. El 29 de julio, su abogado, David Boies, mandó a CrowdStrike una carta en la que le reclamaba por el incidente y la amenazaba con demandarla [14]. Dos días después, el 31 de julio, Bastian dijo a CNBC: «No puede llegar a una operación de misión crítica 24/7 y decirnos que tiene un error» [10]. Explicó por qué Delta sufrió más: «Somos, por mucho, los que más usamos ambos [Microsoft y CrowdStrike] en la industria, y por eso nos pegó más fuerte en nuestra capacidad de recuperación» [10]. Meses después, en su demanda, presentada el 25 de octubre de 2024 en la corte estatal del condado de Fulton, en Georgia, Delta sostiene que no tenía activadas las actualizaciones automáticas y que la actualización le llegó de todos modos, y que «si CrowdStrike hubiera probado la Actualización Defectuosa en una sola computadora antes de desplegarla, la computadora se habría caído» [9]. Reclama más de 500 millones de dólares por allanamiento informático, incumplimiento de contrato y negligencia grave, entre otros cargos [9].

La versión de CrowdStrike. Su abogado, Michael Carlinsky, respondió a esa carta el 4 de agosto. Según su carta, horas después del incidente CrowdStrike ofreció ayuda a Delta; su director general ofreció personal en sitio al de Delta y «no recibió respuesta»; al dar seguimiento, le dijeron que «los recursos en sitio no eran necesarios» [14]. Pidió que Delta explicara «por qué todos sus competidores, ante retos similares, restablecieron sus operaciones mucho más rápido», y advirtió que su responsabilidad está «limitada por contrato a un monto de un solo dígito en millones» [14]. En su propia demanda, presentada el mismo 25 de octubre en la corte federal, CrowdStrike alega que otras grandes aerolíneas volvieron a operar casi normalmente el 20 de julio, y que fue «la propia respuesta e infraestructura de TI de Delta» lo que alargó su recuperación [8].

La versión de Microsoft. Delta había anunciado que también le reclamaría a Microsoft [6], y Microsoft no se quedó callada. Su abogado, Mark Cheffo, escribió el 6 de agosto, según reportaron CNBC y NBC News. La carta dice que Microsoft ofreció ayuda sin costo todos los días del 19 al 23 de julio y que Delta la declinó; que un empleado de Delta contestó el 22 de julio «Todo bien…»; que el director general de Microsoft, Satya Nadella, escribió a Bastian el 24 de julio y no tuvo respuesta; y que el sistema de seguimiento de tripulaciones no corría en Windows ni en Azure, sino que lo atendían «otros proveedores de tecnología, como IBM». Remató: «Delta, a diferencia de sus competidores, aparentemente no ha modernizado su infraestructura de TI» [15].

La réplica de Delta. La aerolínea respondió que desde 2016 ha invertido «miles de millones de dólares» en sistemas [15]. Boies volvió a escribir el 8 de agosto: «No hay base, ninguna, para sugerir que Delta fuera de algún modo responsable del software defectuoso» [16]. Según el medio especializado Skift, Delta sostiene además que la oferta de ayuda en sitio llegó cuando ya había restaurado la mayoría de sus sistemas críticos [16].

Dónde quedó todo

A más de dos años del apagón, el pleito entre Delta y CrowdStrike sigue abierto.

En mayo de 2025, la jueza Kelly Lee Ellerbe, de la corte del condado de Fulton, desechó las reclamaciones de Delta por tergiversación intencional y fraude por omisión, pero dejó seguir las de negligencia, incluida la teoría de negligencia grave, y la de allanamiento informático [17]. El abogado de CrowdStrike dijo entonces que el peor escenario para su cliente sería un pago «de un solo dígito en millones» [17]. En su reporte trimestral a la autoridad bursátil de agosto de 2026, CrowdStrike informó que la demanda de Delta en el condado de Fulton seguía en la etapa de descubrimiento, en la que las partes se piden e intercambian pruebas antes del juicio [18]. Es decir, todavía no había juicio ni sentencia.

El regulador ya cerró su parte. Según Reuters, que retomó una nota de Politico, el DOT cerró la investigación sin multa. La decisión se tomó en noviembre del año anterior y se conoció en junio de 2026. Un vocero dijo que la revisión encontró que los pasajeros de Delta recibieron «reembolsos rápidos, asistencia adecuada con el equipaje» y ayuda apropiada para pasajeros con discapacidad [7].

Quién debe pagar cuánto lo decidirá un tribunal. Este artículo no toma partido en eso. Lo que sí podemos hacer es mirar lo que no está en disputa y preguntar qué enseña.

Qué enseña este caso

1. El error fue de otro; la recuperación fue propia

Ninguna de las tres versiones discute lo básico: la falla la introdujo un proveedor, y le llegó a muchas empresas a la vez. Lo que varió fue el tiempo de cada una para volver. CrowdStrike puede responder por su error en un tribunal. Pero los días que tardó la operación los pagaron los pasajeros y la propia aerolínea, y ese tiempo nadie lo devuelve. Delta reclama 500 millones; CrowdStrike dice que su contrato limita lo que pagaría a menos de diez. Sea cual sea el resultado, el contrato con el proveedor no sustituye a la capacidad de levantarse.

La pregunta para un comité no es «¿y si nuestro proveedor falla?». Es: cuando falle, ¿cuánto tardamos nosotros?

2. No se repara lo que no se tiene inventariado

Para reparar a mano, uno por uno, los 40,000 servidores que según Bastian tuvo que reiniciar Delta [9][10], primero hay que saber cuáles son, dónde están, quién puede entrar a cada uno y en qué orden conviene levantarlos. Y para los que tienen el disco cifrado, dónde está la clave de cada uno [4][5]. Si esas claves viven en un sistema que también se cayó, la recuperación se detiene antes de empezar.

Un inventario útil en una emergencia no es una hoja con nombres de servidores. Dice qué hace cada equipo, de qué depende, quién lo atiende, cómo se entra cuando la red o el directorio de usuarios no responden, y qué se levanta primero. Se escribe en calma y se guarda donde se pueda consultar con todo lo demás apagado.

3. Lo que se recupera al final no son las computadoras

El caso lo muestra con claridad: las computadoras de Delta se fueron reparando, y aun así siguió cancelando vuelos. Según la propia Delta, el sistema que asigna tripulaciones tenía que absorber una montaña de cambios acumulados [11]. En su versión, el cuello de botella fue un sistema de negocio, no una máquina.

Por eso un plan de recuperación no termina en «el servidor ya enciende». Tiene que responder qué sistemas de negocio vuelven primero, cuánto tardan en ponerse al corriente con lo que se acumuló, qué se hace a mano mientras tanto y quién decide qué operaciones se suspenden para que la fila deje de crecer.

4. Un procedimiento que nunca se ensayó es una hipótesis

En la carta del 4 de agosto, CrowdStrike pidió a Delta conservar, entre otras cosas, sus planes de respaldo, recuperación y continuidad, «y cualquier prueba relacionada con esos planes» [14]. No sabemos qué tenía escrito Delta ni qué había ensayado; eso es justo lo que el juicio puede revelar. Pero la pregunta del abogado es la correcta para cualquier empresa: no basta con tener el plan; importa cuándo se probó por última vez y cuánto tardó.

Un ensayo descubre lo que el papel no dice: la clave de recuperación que nadie encuentra, el acceso que depende del mismo sistema caído, el paso que solo una persona sabe hacer.

5. Un equipo que ya conoce el procedimiento

Reparar miles de equipos a mano exige muchas manos que sepan exactamente qué hacer, con instrucciones claras y sin improvisar. En una emergencia, cada persona que tiene que aprender el procedimiento ese día es tiempo perdido. Los equipos que se recuperan rápido no son necesariamente los más grandes, sino los que ya saben quién hace qué.

6. Decida antes quién entra a ayudar

CrowdStrike y Microsoft dicen que ofrecieron ayuda y que Delta la declinó; Delta dice que la ayuda llegó tarde [14][15][16]. Más allá de quién tenga razón, el episodio deja una lección práctica: en plena crisis, aceptar ayuda externa implica dar accesos, explicar el entorno y coordinar a gente nueva, y eso cuesta tiempo. Esa decisión conviene tomarla antes: quién puede entrar, con qué accesos, quién lo coordina y cuándo se activa.

Cinco preguntas para su próximo comité

1. Si mañana un proveedor deja inservibles la mitad de nuestras computadoras, ¿cuánto tardamos en volver? ¿Lo sabemos porque lo medimos o porque lo suponemos?
2. ¿Tenemos un inventario que sirva con todo apagado? Qué equipos, de qué dependen, cómo se entra y en qué orden se levantan.
3. ¿Dónde están las claves de recuperación de los discos cifrados, y se pueden consultar si el directorio de usuarios está caído?
4. ¿Qué sistema de negocio sería nuestro «sistema de tripulaciones»? El que, aunque las máquinas vuelvan, tarda días en ponerse al corriente.
5. ¿Cuándo ensayamos por última vez la recuperación, quién participó y qué falló?

Si dos o más respuestas son «no sé», el riesgo no está en el proveedor: está en lo que falta preparar.

Por dónde empezar esta semana

No hace falta un proyecto grande. Elija un sistema crítico, el que más le dolería tener detenido un día, y pida a su equipo tres cosas por escrito: la lista de equipos de los que depende, los pasos para levantarlo desde cero si nada más funciona, y el nombre de quién los ejecuta. Después pídale que los siga en un ambiente de prueba, con un cronómetro. Lo que tarde, y lo que falte en el papel, es su punto de partida.

Qué hace Hábil: cómo puede ayudarle

Hábil no participó en el incidente de CrowdStrike ni en la recuperación de Delta. Lo que sigue es lo que hacemos, en general, para dos momentos: el día de la caída y los meses de antes.

Cuando algo crítico se cae, nuestro Equipo SWAT entra con método: primero contiene el daño y estabiliza lo caído, después encuentra qué pasó y desde cuándo, corrige la causa de fondo y recupera la operación por pasos, para no crear otro problema. Al terminar le entrega una memoria técnica con la evidencia: lo que se encontró, lo que se hizo, cómo se verificó y lo que queda de su lado. Trabajamos con su equipo, no en su lugar, en la nube o en su centro de datos.

Y antes de la urgencia, con Aprovisionamiento de infraestructura le ayudamos a dejar una base sólida y documentada, para que el día que algo falle su equipo sepa qué levantar primero y cómo.

La primera conversación es sin costo: su objetivo es ubicar qué sistema le dolería más perder, qué tiene hoy para levantarlo y qué le falta. Escríbanos por WhatsApp.

Preguntas frecuentes

¿Fue un ciberataque?

No. Delta, CrowdStrike y Microsoft lo tratan como una actualización defectuosa. El análisis de CrowdStrike describe un error de programación y de validación en su propio contenido, no una intrusión [1][2].

¿Por qué no se arregló a distancia, si el error se corrigió en 78 minutos?

Porque los equipos afectados se caían antes de terminar de arrancar y no alcanzaban a descargar la corrección. En muchos, la reparación pedía estar frente a la máquina: arrancar en modo seguro, borrar un archivo y, en los discos cifrados, capturar una clave de recuperación [4][5]. Delta alega que en su caso no hubo forma de hacerlo a distancia [9].

¿Por qué Delta tardó más que otras aerolíneas?

Es justo lo que está en disputa. Delta dice que dependía más que nadie de la tecnología afectada y que su sistema de tripulaciones no pudo con el volumen de cambios [10][11]. CrowdStrike y Microsoft atribuyen la lentitud a la infraestructura y a la respuesta de Delta [8][15]. Lo decidirá un tribunal.

¿Mi empresa está en riesgo si no usa CrowdStrike?

Cualquier empresa que reciba actualizaciones automáticas de un proveedor, sea de seguridad, del sistema operativo o de una aplicación, depende de que esa actualización salga bien. La pregunta útil no es qué proveedor usa, sino cuánto tardaría en recuperarse si una actualización falla.

¿El contrato con el proveedor no me protege?

Le puede dar un derecho a reclamar, pero no le devuelve la operación. En este caso, CrowdStrike sostiene que su responsabilidad está limitada por contrato a un monto de un solo dígito en millones de dólares, frente a los más de 500 millones que reclama Delta [9][14].

¿Qué es lo primero que conviene preparar?

Un inventario de un sistema crítico que se pueda consultar con todo apagado, un procedimiento de recuperación escrito y ensayado con cronómetro, y nombres de quién lo ejecuta.

Las citas están traducidas del inglés. Las versiones de Delta, CrowdStrike y Microsoft son lo que cada parte afirma en sus cartas y demandas, no hechos probados. Estado del proceso según el último reporte trimestral de CrowdStrike (agosto de 2026), revisado el 21 de octubre de 2026.