78 minutos de erro, cinco dias de pane: o que a CrowdStrike e a Delta ensinam sobre se recuperar

O erro durou 78 minutos e foi de outra empresa. A recuperação durou de um a cinco dias, e essa foi de cada uma. Em 19 de julho de 2024, a mesma falha atingiu várias companhias aéreas dos Estados Unidos. Na segunda-feira seguinte, a maioria operava quase normalmente. A Delta Air Lines cancelou cerca de 7.000 voos em cinco dias.

Por que a mesma falha custou um fim de semana a umas e cinco dias a outra? A pergunta continua em aberto, e a Delta e a CrowdStrike a disputam nos tribunais. A Delta diz que dependia mais do que ninguém da tecnologia afetada; a CrowdStrike, que o que prolongou a recuperação foram a resposta e a infraestrutura da própria Delta. Este artigo não resolve essa briga. O que o caso ensina a qualquer empresa, ganhe quem ganhar, é que o tempo que ela leva para voltar se decide em boa parte antes da falha, com o que deixou preparado.

Esta é a história documentada, hora a hora, com o que diz cada parte: a Delta e a CrowdStrike, que processaram uma à outra, e a Microsoft, que respondeu por carta. No fim, o que ela ensina a qualquer empresa que dependa dos próprios sistemas, o que hoje é quase todas.

Quinta-feira, 10:09 da noite na Cidade do México

A CrowdStrike vende um programa de segurança chamado Falcon. O sensor dele é instalado nos computadores e servidores que a empresa cliente quer proteger e vigia o que acontece dentro do sistema operacional para detectar ataques. Para reconhecer técnicas novas, recebe com frequência pequenas atualizações de conteúdo: não mudam o programa, só lhe ensinam o que procurar.

Na sexta-feira, 19 de julho de 2024, às 04:09 no horário universal (UTC), a CrowdStrike publicou uma dessas atualizações para os computadores com Windows [1]. Na costa leste dos Estados Unidos eram 12:09 da madrugada [8]. Na Cidade do México, 10:09 da noite de quinta-feira.

A atualização trazia dois modelos novos para vigiar como os programas se comunicam entre si dentro do Windows. Um deles pedia para verificar um dado que ninguém tinha verificado antes. A análise de causa raiz que a CrowdStrike publicou em 6 de agosto explica assim: esse tipo de modelo, criado em fevereiro de 2024, definia 21 campos de entrada, mas o código que o executava só lhe entregava 20 [2]. Durante meses nada aconteceu, porque os testes e os modelos anteriores usavam um curinga no campo 21: «qualquer valor serve». O de 19 de julho foi o primeiro que de fato comparava com esse campo [2].

O programa tentou ler o dado número 21 fora da memória reservada para os 20 que recebia, e o Windows parou [1][2]. A ferramenta que deveria validar o conteúdo antes de enviá-lo tinha um erro próprio e o deixou passar [1]. O que veio depois, milhões de pessoas viram: a tela azul.

Às 05:27 UTC, 78 minutos depois, a CrowdStrike retirou a atualização [1]. Os computadores que se conectaram depois já não a receberam. Mas os que a receberam não conseguiam baixar a versão corrigida, porque travavam antes de terminar de iniciar.

Sexta-feira: 8,5 milhões de telas azuis

No dia seguinte, a Microsoft estimou o alcance: 8,5 milhões de dispositivos com Windows, «menos de um por cento de todas as máquinas Windows» (tradução própria) [3]. Era pouco em porcentagem e enorme em consequências. A Microsoft explicou assim: o impacto econômico e social refletia que a CrowdStrike é usada por empresas que operam muitos serviços críticos [3]. As companhias aéreas estavam entre elas.

A correção existia desde a madrugada. O difícil era aplicá-la. As instruções da Microsoft pediam, computador por computador, iniciar em modo de segurança a partir da tela de recuperação, entrar na pasta da CrowdStrike, apagar os arquivos C-00000291*.sys e reiniciar [4]. E havia um detalhe que transformou minutos em horas: nos computadores com o disco criptografado com o BitLocker, a ferramenta de criptografia do Windows, essa inicialização podia pedir a chave de recuperação [4][5]. Uma chave longa, diferente para cada computador, que alguém precisava ter guardado em um lugar acessível enquanto todo o resto estava fora do ar.

Em outras palavras, em muitos computadores o reparo exigia alguém na frente da máquina. A Microsoft publicou depois uma ferramenta em pen drive para automatizar parte da correção, mas também era preciso conectá-la computador por computador [4]. A Delta alegaria no processo que, no caso dela, os computadores «tiveram que ser corrigidos manualmente, um de cada vez, e não podiam ser consertados remotamente» (tradução própria) [9]. O CEO, Ed Bastian, disse à CNBC que a companhia teve que reiniciar à mão 40.000 servidores [10].

A CrowdStrike relatou uma recuperação rápida em sua base de clientes: mais de 97 % dos sensores de Windows estavam de novo on-line em 24 de julho e cerca de 99 % em 29 de julho, em comparação com a semana anterior [5][2]. Os números gerais pareciam bons. Mas a média escondia quem não estava se levantando.

Sábado e domingo: umas se levantam, outra não

As companhias aéreas vivem de um quebra-cabeça montado todos os dias: que avião vai para que rota, que piloto e que tripulação vão em cada voo, e se cada pessoa cumpre as horas de descanso que a lei exige. Se o sistema que monta esse quebra-cabeça para, os aviões podem estar prontos e mesmo assim não decolar, porque ninguém sabe com certeza quem está onde.

Várias companhias afetadas cancelaram voos na sexta-feira. O que importa é o que aconteceu depois. Segundo o balanço da agência AP da segunda-feira, 22 de julho, a United, a segunda mais atingida, tinha cancelado quase 1.500 voos desde sexta-feira, mas naquela segunda, no meio da manhã, só somava 17. American, Spirit, Frontier e Allegiant estavam quase na normalidade. Southwest e Alaska, que não usam a CrowdStrike, tiveram poucos cancelamentos [11].

A Delta, por sua vez, somava mais de 5.500 voos cancelados desde sexta-feira, e na segunda cancelou pelo menos mais 700. Naquele dia, a Delta e suas companhias regionais respondiam por cerca de dois terços de todos os cancelamentos do mundo, «incluídos quase todos os dos Estados Unidos» (tradução própria) [11].

Segunda-feira: o sistema que não conseguia se pôr em dia

O que estava falhando, se os computadores já estavam sendo reparados? A Delta explicou nesses dias, com suas próprias palavras.

Bastian escreveu aos clientes que uma das ferramentas de acompanhamento de tripulações tinha sido afetada e não conseguia processar o enorme volume de mudanças que o apagão provocou. Com aviões cheios em pleno verão, acima de 90 % de ocupação, isso ia «limitando nossas capacidades de reacomodação» (tradução própria) [11]. Aos funcionários, disse que faltavam «mais alguns dias» para que «o pior fique claramente para trás» (tradução própria) [11].

O diretor de sistemas da Delta, Rahul Samant, foi mais preciso. Segundo a AP, disse que os dois aplicativos mais difíceis de pôr de pé de novo foram o que administra o tráfego no aeroporto de Atlanta, seu principal centro de operações, e o que designa pilotos e comissários aos voos. Este último já estava rodando, mas «temos um atraso a recuperar» (tradução própria); e, segundo a AP, Samant disse que continuavam surgindo problemas novos [11].

Aí está o coração do caso. Os computadores podem ser reparados um a um. Mas um sistema que coordena milhares de pessoas não volta ao normal só por ser ligado: precisa absorver todas as mudanças acumuladas enquanto esteve parado, e cada voo cancelado gera mais mudanças. É uma fila que cresce enquanto alguém tenta esvaziá-la.

Terça-feira: chega o regulador

Na terça-feira, 23 de julho, o Departamento de Transportes dos Estados Unidos (DOT) abriu uma investigação contra a Delta. Segundo a AP, o departamento disse que a abriu depois de ver as interrupções generalizadas e contínuas nos voos da Delta «e relatos de falhas preocupantes de atendimento ao cliente» (tradução própria) [12]. O secretário de Transportes, Pete Buttigieg, já tinha falado com Bastian e disse que o órgão havia recebido «centenas de reclamações» (tradução própria) [11].

Na quarta-feira, 24, às 7:45 da manhã, Bastian publicou uma nova carta aos clientes: os cancelamentos e atrasos de terça tinham caído 50 % em relação à segunda, ele esperava cancelamentos mínimos na quarta e uma quinta normal. Ofereceu milhas e vales de viagem «como mais um gesto de desculpas» (tradução própria) [13].

Em 31 de julho, Bastian disse à CNBC que, nos sete dias anteriores, a Delta tinha tido menos de 100 cancelamentos em mais de 30.000 voos [10]. A operação estava de volta. O custo mal começava a ser contado.

A conta

Em seu relatório à autoridade do mercado de valores de 8 de agosto, a Delta pôs os números: cerca de 7.000 cancelamentos em cinco dias [6]. Um impacto direto na receita de 380 milhões de dólares, sobretudo por reembolsos e compensações em dinheiro e em milhas, e 170 milhões de despesa adicional, principalmente reembolso de despesas de clientes e custos de tripulação. Em contrapartida, pelos voos que não voaram, gastou uns 50 milhões a menos em combustível [6]. Líquido, cerca de 500 milhões de dólares.

«Uma interrupção operacional desta duração e magnitude é inaceitável, e nossos clientes e funcionários merecem algo melhor» (tradução própria), disse Bastian nesse mesmo relatório [6]. As pessoas afetadas foram mais de um milhão, segundo o processo da Delta [9]; 1,3 milhão, segundo a Reuters [7].

Três versões da mesma pane

A partir daqui, a história vira disputa. Convém lê-la como o que é: três partes com advogados, cada uma contando a sua versão, mas um único litígio, de duas partes. A Delta e a CrowdStrike processaram uma à outra no mesmo dia, cada uma em um tribunal diferente. A Microsoft respondeu por carta, e nesses processos não figura como parte. O que segue foi tirado das próprias cartas e processos.

A versão da Delta. Em 29 de julho, o advogado da Delta, David Boies, mandou à CrowdStrike uma carta em que a responsabilizava pelo incidente e a ameaçava com um processo [14]. Dois dias depois, em 31 de julho, Bastian disse à CNBC: «Não se pode chegar a uma operação de missão crítica 24/7 e nos dizer que há um erro» (tradução própria) [10]. Explicou por que a Delta sofreu mais: «Somos, de longe, os que mais usam ambos [Microsoft e CrowdStrike] no setor, e por isso fomos os mais atingidos em capacidade de recuperação» (tradução própria) [10]. Meses depois, no processo, apresentado em 25 de outubro de 2024 no tribunal estadual do condado de Fulton, na Geórgia, a Delta sustenta que não tinha ativado as atualizações automáticas e que a atualização chegou mesmo assim, e que «se a CrowdStrike tivesse testado a Atualização Defeituosa em um único computador antes de implantá-la, o computador teria travado» (tradução própria) [9]. Pede mais de 500 milhões de dólares por invasão informática, descumprimento de contrato e negligência grave, entre outras acusações [9].

A versão da CrowdStrike. O advogado da empresa, Michael Carlinsky, respondeu a essa carta em 4 de agosto. Segundo a carta, horas depois do incidente a CrowdStrike ofereceu ajuda à Delta; o CEO da CrowdStrike ofereceu pessoal no local ao CEO da Delta e «não obteve resposta»; ao dar seguimento, ouviu que «os recursos no local não eram necessários» (tradução própria) [14]. Pediu que a Delta explicasse «por que seus concorrentes, diante de desafios semelhantes, restabeleceram todos as operações muito mais rápido», e advertiu que sua responsabilidade está «limitada por contrato a um valor de um só dígito na casa dos milhões» (tradução própria) [14]. No próprio processo, apresentado no mesmo 25 de outubro no tribunal federal, a CrowdStrike alega que outras grandes companhias aéreas voltaram a operar quase normalmente em 20 de julho, e que foram «a própria resposta e a infraestrutura de TI da Delta» (tradução própria) que prolongaram sua recuperação [8].

A versão da Microsoft. A Delta tinha anunciado que também cobraria da Microsoft [6], e a Microsoft não ficou calada. O advogado da empresa, Mark Cheffo, escreveu em 6 de agosto, segundo noticiaram a CNBC e a NBC News. A carta diz que a Microsoft ofereceu ajuda sem custo todos os dias de 19 a 23 de julho e que a Delta a recusou; que um funcionário da Delta respondeu em 22 de julho «Tudo bem…»; que o CEO da Microsoft, Satya Nadella, escreveu a Bastian em 24 de julho e não teve resposta; e que o sistema de acompanhamento de tripulações não rodava em Windows nem em Azure, mas era atendido por «outros fornecedores de tecnologia, como a IBM». Arrematou: «A Delta, ao contrário de seus concorrentes, aparentemente não modernizou sua infraestrutura de TI» (tradução própria) [15].

A réplica da Delta. A companhia respondeu que desde 2016 investiu «bilhões de dólares» em sistemas (tradução própria) [15]. Boies voltou a escrever em 8 de agosto: «Não há base, nenhuma, para sugerir que a Delta fosse de algum modo responsável pelo software defeituoso» (tradução própria) [16]. Segundo o veículo especializado Skift, a Delta sustenta ainda que a oferta de ajuda no local chegou quando já tinha restaurado a maioria de seus sistemas críticos [16].

Onde tudo ficou

Mais de dois anos depois da pane, o litígio entre a Delta e a CrowdStrike continua aberto.

Em maio de 2025, a juíza Kelly Lee Ellerbe, do tribunal do condado de Fulton, rejeitou os pedidos da Delta por deturpação intencional e fraude por omissão, mas deixou seguir os de negligência, incluída a tese de negligência grave, e o de invasão informática [17]. O advogado da CrowdStrike disse então que o pior cenário para sua cliente seria um pagamento «de um só dígito na casa dos milhões» (tradução própria) [17]. Em seu relatório trimestral à autoridade do mercado de valores de agosto de 2026, a CrowdStrike informou que o processo da Delta no condado de Fulton continuava na fase de discovery, em que as partes pedem e trocam provas entre si antes do julgamento [18]. Ou seja, ainda não havia julgamento nem sentença.

O regulador já encerrou sua parte. Segundo a Reuters, que retomou uma reportagem do Politico, o DOT encerrou a investigação sem multa. A decisão foi tomada em novembro do ano anterior e veio a público em junho de 2026. Um porta-voz disse que a análise constatou que os passageiros da Delta receberam «reembolsos rápidos, assistência adequada com a bagagem» (tradução própria) e ajuda apropriada para passageiros com deficiência [7].

Quem deve pagar quanto, um tribunal decidirá. Este artigo não toma partido nisso. O que podemos fazer é olhar o que não está em disputa e perguntar o que ensina.

O que este caso ensina

1. O erro foi de outro; a recuperação foi própria

Nenhuma das três versões discute o básico: a falha foi introduzida por um fornecedor e chegou a muitas empresas ao mesmo tempo. O que variou foi o tempo de cada uma para voltar. A CrowdStrike pode responder por seu erro em um tribunal. Mas os dias que a operação levou foram pagos pelos passageiros e pela própria companhia, e esse tempo ninguém devolve. A Delta pede 500 milhões; a CrowdStrike diz que o contrato limita o que pagaria a menos de dez. Seja qual for o resultado, o contrato com o fornecedor não substitui a capacidade de se levantar.

A pergunta para um comitê não é «e se o nosso fornecedor falhar?». É: quando falhar, quanto tempo nós levamos?

2. Não se repara o que não está inventariado

Para consertar à mão, um por um, os 40.000 servidores que, segundo Bastian, a Delta teve que reiniciar [9][10], primeiro é preciso saber quais são, onde estão, quem pode entrar em cada um e em que ordem convém levantá-los. E, para os que têm o disco criptografado, onde está a chave de cada um [4][5]. Se essas chaves vivem em um sistema que também caiu, a recuperação para antes de começar.

Um inventário útil em uma emergência não é uma planilha com nomes de servidores. Diz o que cada equipamento faz, de que depende, quem o atende, como se entra quando a rede ou o diretório de usuários não respondem, e o que se levanta primeiro. É escrito com calma e guardado onde possa ser consultado com todo o resto desligado.

3. O que se recupera no fim não são os computadores

O caso mostra isso com clareza: os computadores da Delta foram sendo reparados, e mesmo assim ela continuou cancelando voos. Segundo a própria Delta, o sistema que designa tripulações precisava absorver uma montanha de mudanças acumuladas [11]. Na versão dela, o gargalo foi um sistema de negócio, não uma máquina.

Por isso um plano de recuperação não termina em «o servidor já liga». Precisa responder que sistemas de negócio voltam primeiro, quanto tempo levam para se pôr em dia com o que se acumulou, o que se faz à mão enquanto isso e quem decide que operações são suspensas para que a fila pare de crescer.

4. Um procedimento que nunca foi ensaiado é uma hipótese

Na carta de 4 de agosto, a CrowdStrike pediu à Delta que preservasse, entre outras coisas, seus planos de backup, recuperação e continuidade, «e quaisquer testes relacionados a esses planos» (tradução própria) [14]. Não sabemos o que a Delta tinha escrito nem o que havia ensaiado; é justamente isso que o julgamento pode revelar. Mas a pergunta do advogado é a certa para qualquer empresa: não basta ter o plano; importa quando foi testado pela última vez e quanto tempo levou.

Um ensaio descobre o que o papel não diz: a chave de recuperação que ninguém encontra, o acesso que depende do mesmo sistema caído, o passo que só uma pessoa sabe fazer.

5. Uma equipe que já conhece o procedimento

Reparar milhares de computadores à mão exige muitas mãos que saibam exatamente o que fazer, com instruções claras e sem improvisar. Em uma emergência, cada pessoa que precisa aprender o procedimento naquele dia é tempo perdido. As equipes que se recuperam rápido não são necessariamente as maiores, mas as que já sabem quem faz o quê.

6. Decida antes quem entra para ajudar

A CrowdStrike e a Microsoft dizem que ofereceram ajuda e que a Delta a recusou; a Delta diz que a ajuda chegou tarde [14][15][16]. Independentemente de quem tenha razão, o episódio deixa uma lição prática: em plena crise, aceitar ajuda externa implica dar acessos, explicar o ambiente e coordenar gente nova, e isso custa tempo. Essa decisão convém tomar antes: quem pode entrar, com que acessos, quem coordena e quando é acionada.

Cinco perguntas para o próximo comitê

1. Se amanhã um fornecedor deixar inutilizados metade dos nossos computadores, quanto tempo levamos para voltar? Sabemos porque medimos ou porque supomos?
2. Temos um inventário que funcione com tudo desligado? Que equipamentos, de que dependem, como se entra e em que ordem se levantam.
3. Onde estão as chaves de recuperação dos discos criptografados, e podem ser consultadas se o diretório de usuários estiver fora do ar?
4. Que sistema de negócio seria o nosso «sistema de tripulações»? Aquele que, mesmo com as máquinas de volta, leva dias para se pôr em dia.
5. Quando ensaiamos a recuperação pela última vez, quem participou e o que falhou?

Se duas ou mais respostas forem «não sei», o risco não está no fornecedor: está no que falta preparar.

Por onde começar esta semana

Não é preciso um projeto grande. Escolha um sistema crítico, aquele cuja parada por um dia mais doeria à empresa, e peça à equipe três coisas por escrito: a lista de equipamentos dos quais ele depende, os passos para levantá-lo do zero se nada mais funcionar, e o nome de quem os executa. Depois, peça que ela os siga em um ambiente de teste, com um cronômetro. O tempo que levar, e o que faltar no papel, é o ponto de partida.

O que a Hábil faz: como pode ajudar

A Hábil não participou do incidente da CrowdStrike nem da recuperação da Delta. O que segue é o que fazemos, em geral, para dois momentos: o dia da pane e os meses anteriores.

Quando algo crítico cai, a nossa Equipe SWAT entra com método: primeiro contém o dano e estabiliza o que caiu, depois descobre o que aconteceu e desde quando, corrige a causa de fundo e recupera a operação por etapas, para não criar outro problema. Ao terminar, entrega à empresa um relatório técnico com a evidência: o que se encontrou, o que se fez, como se verificou e o que fica do lado dela. Trabalhamos com a equipe da empresa, não no lugar dela, na nuvem ou no data center próprio.

E antes da urgência, com Provisionamento de infraestrutura, ajudamos a deixar uma base sólida e documentada, para que, no dia em que algo falhar, a equipe saiba o que levantar primeiro e como.

A primeira conversa é sem custo: o objetivo é identificar que sistema mais doeria perder, o que a empresa tem hoje para levantá-lo e o que falta. Escreva-nos pelo WhatsApp.

Perguntas frequentes

Foi um ciberataque?

Não. A Delta, a CrowdStrike e a Microsoft tratam o caso como uma atualização defeituosa. A análise da CrowdStrike descreve um erro de programação e de validação no próprio conteúdo, não uma intrusão [1][2].

Por que não foi consertado remotamente, se o erro foi corrigido em 78 minutos?

Porque os computadores afetados travavam antes de terminar de iniciar e não conseguiam baixar a correção. Em muitos, o reparo exigia estar na frente da máquina: iniciar em modo de segurança, apagar um arquivo e, nos discos criptografados, digitar uma chave de recuperação [4][5]. A Delta alega que, no caso dela, não houve como fazer isso remotamente [9].

Por que a Delta demorou mais que outras companhias aéreas?

É justamente o que está em disputa. A Delta diz que dependia mais do que ninguém da tecnologia afetada e que seu sistema de tripulações não deu conta do volume de mudanças [10][11]. A CrowdStrike e a Microsoft atribuem a lentidão à infraestrutura e à resposta da Delta [8][15]. Um tribunal decidirá.

A empresa corre risco se não usa a CrowdStrike?

Qualquer empresa que receba atualizações automáticas de um fornecedor, seja de segurança, do sistema operacional ou de um aplicativo, depende de que essa atualização saia bem. A pergunta útil não é que fornecedor a empresa usa, mas quanto tempo levaria para se recuperar se uma atualização falhar.

O contrato com o fornecedor não protege a empresa?

Pode dar um direito de cobrar, mas não devolve a operação. Neste caso, a CrowdStrike sustenta que sua responsabilidade está limitada por contrato a um valor de um só dígito na casa dos milhões de dólares, diante dos mais de 500 milhões que a Delta cobra [9][14].

O que convém preparar primeiro?

Um inventário de um sistema crítico que possa ser consultado com tudo desligado, um procedimento de recuperação escrito e ensaiado com cronômetro, e os nomes de quem o executa.

As citações foram traduzidas do inglês. As versões da Delta, da CrowdStrike e da Microsoft são o que cada parte afirma em suas cartas e processos, não fatos provados. Estado do processo segundo o último relatório trimestral da CrowdStrike (agosto de 2026), revisado em 21 de outubro de 2026.