It was 04:09 UTC on July 19, 2024.
For much of the world, it was an ordinary Friday morning. Businesses were preparing to open. Hospital staff were beginning their shifts. Airport teams were getting ready for the day’s first departures. Behind the scenes, computers were processing information, managing operations, and running the systems that modern businesses depend on without giving them a second thought.
Then a software update went out.
It did not come from a hacker attempting to break into corporate networks. It was not the result of a ransomware attack. It was not a coordinated assault on the world’s digital infrastructure.
It came from CrowdStrike, a major cybersecurity company whose software businesses use to detect and respond to threats.
The update was part of the company’s regular security operations. But a defect in the update caused affected Windows computers to crash, displaying the dreaded Blue Screen of Death.
CrowdStrike released the faulty configuration update at 04:09 UTC. The company reverted it at 05:27 UTC, creating a 78-minute window during which eligible systems could receive the defective update.
The damage, however, did not end when that window closed.
Microsoft later estimated that approximately 8.5 million Windows devices were affected worldwide. Airlines cancelled flights. Healthcare providers experienced technology disruptions. Financial services and broadcasters encountered operational problems. Businesses across different industries suddenly had to deal with a question they rarely expect to confront on an ordinary working day:
What happens when the software your business depends on stops working?
The incident became one of the most consequential technology disruptions in recent history, demonstrating how a technical failure in one widely deployed product could affect organizations far beyond its developer.
But the most important part of this story is not the number of computers that crashed.
It is what the incident reveals about the relationship between technology, business operations, and the ability to recover when something goes wrong.
What Happened That Morning?
To understand why the outage became so disruptive, it helps to understand what failed.
CrowdStrike provides cybersecurity software called Falcon. One of its functions is to help organizations detect suspicious activity and protect Windows systems against emerging threats.
Security software must continually adapt to new threats. CrowdStrike therefore distributes updates that help its technology recognize and respond to changing attack techniques.
On July 19, 2024, the company released a Rapid Response Content configuration update for Windows systems.
The update contained an undetected defect. When affected systems processed the defective content, it triggered a logic error that caused Windows to crash.
This was not a conventional cyberattack. It was a failure within a legitimate security update intended to protect customers.
That distinction matters.
A cyberattack involves an adversary attempting to compromise systems or disrupt operations. The CrowdStrike incident demonstrated that significant disruption can also result from an error in software distributed through an ordinary update process.
The very mechanism intended to help protect businesses became the source of the disruption.
CrowdStrike subsequently identified the problem and reverted the faulty content update. However, reverting an update did not automatically restore every computer that had already crashed. Many affected machines required remediation before they could operate normally again.
In other words, stopping the faulty update and recovering the affected computers were two different tasks.
That difference helps explain why the incident continued to affect organizations after the original 78-minute window had ended.
Why Did a Single Update Affect So Many Businesses?
The answer is not simply that CrowdStrike had many customers.
It is that its software operated within the technology environments of organizations that depended on Windows computers for essential work.
Consider how a business operates today.
Employees use computers to access customer records, communicate with colleagues, process transactions, manage schedules, coordinate deliveries, and monitor internal systems. Those computers connect to applications, databases, cloud services, and other systems that make the business function.
When one component fails, the consequences depend on what it supports and how closely it is connected to the rest of the operation.
A computer used for an occasional administrative task may be inconvenient to lose temporarily. A computer needed to coordinate flights, access clinical information, or support a time-sensitive operational process may be far more consequential.
The CrowdStrike outage exposed this difference on a global scale.
The same broad technical failure affected organizations with very different responsibilities, operating procedures, and recovery requirements.
For some, the immediate problem was a computer that needed repair. For others, the problem extended into staffing, customer service, scheduling, financial losses, and the ability to maintain essential operations.
The severity of a technology failure is not determined by the software alone. It is also determined by what the business has built around it.
That is where the story becomes especially relevant to business owners.
When Airports Could No Longer Operate Normally
Air travel offered one of the most visible examples of the disruption.
Airlines rely on interconnected technology to manage reservations, check-in, boarding, flight schedules, crew assignments, baggage handling, and customer communication.
When important systems become unavailable, the consequences can extend well beyond the computers experiencing the original problem.
A passenger may be unable to check in. An airline employee may be unable to access the information needed to complete a task. A flight may be delayed because the people coordinating it cannot complete their normal procedures.
Even when some systems remain operational, the loss of other connected systems can make it difficult to maintain the normal flow of an airline’s operations.
Delta Air Lines experienced particularly severe and prolonged disruption.
According to Delta’s August 2024 filing with the U.S. Securities and Exchange Commission, the outage disrupted its operations and caused approximately 7,000 flight cancellations over five days.
The airline estimated that the incident had an impact of approximately $380 million on direct revenue, primarily through refunds and customer compensation. It also estimated $170 million in additional non-fuel expenses associated with the outage and operational recovery, including customer reimbursements and crew-related costs.
Delta said it was pursuing legal claims against CrowdStrike and Microsoft to recover damages totaling at least $500 million.
These figures must be understood in their proper context: the $500 million was Delta’s stated damages claim, not a final determination that CrowdStrike owed that amount.
Nevertheless, the incident illustrates the potential cost of a technology disruption that continues to affect an operation after the initial technical failure.
The problem was no longer limited to repairing computers. Delta also had to deal with the consequences of cancelled flights, disrupted schedules, customer compensation, and the work required to restore normal operations.
A business can stop experiencing the original technical failure and still be dealing with its financial consequences days later.
For a business owner, that distinction is important. Recovery is not complete simply because a computer switches on again. Recovery also means restoring the activities, relationships, and commitments that were affected while the system was unavailable.
Hospitals Faced a Different Kind of Disruption
For hospitals, technology downtime carries a different set of consequences.
Healthcare organizations use digital systems to manage patient records, coordinate appointments, support clinical workflows, communicate information, and perform administrative tasks.
When those systems become unavailable, staff may have to change how they work while attempting to maintain patient care.
The CrowdStrike incident prompted concerns about precisely these risks.
A 2025 study published in JAMA Network Open examined technology disruptions associated with the outage. Researchers assessed 2,232 hospitals with available data and found detectable network service disruptions at 759 of them immediately following the incident.
The researchers identified 1,098 disrupted digital services. Of those, 239 were classified as direct patient-facing services, while others were associated with operational, research-related, or unclassified functions.
The findings provide documented evidence that the outage affected digital services connected to hospital operations and patient care.
However, the study did not establish that hospitals collectively spent $2 billion on manual workarounds. Nor did it calculate a total financial bill for the healthcare sector.
That distinction is important because a serious disruption does not automatically tell us its total financial cost.
The consequences can include delayed workflows, staff time spent restoring systems, operational difficulties, and risks to the continuity of care. Establishing the total financial impact would require additional evidence about those costs across the affected organizations.
The broader lesson remains significant.
Healthcare organizations cannot assume that digital systems will always be available simply because they are essential. They need ways to manage critical activities when normal technology becomes unavailable.
The same principle applies to businesses in less obviously critical industries.
A company may not be responsible for patient care, but it may still depend on its customer database, payment system, inventory platform, scheduling software, or communication tools to deliver what it promises.
The consequences differ. The underlying question is the same: what happens to the operation when an essential system becomes unavailable?
The Financial Damage Was Significant. But What Can We Actually Prove?
When a disruption affects millions of devices and organizations across multiple industries, it is tempting to attach one enormous number to the damage.
A single global figure makes the story easier to tell. It also creates a powerful headline.
But the size of an incident and the precision of its financial measurement are two different things.
The CrowdStrike outage clearly caused substantial disruption. Delta publicly estimated hundreds of millions of dollars in damages. Healthcare researchers documented widespread network service interruptions. Businesses in numerous sectors reported operational problems.
However, those facts do not establish a verified global economic loss of $10 billion.
Calculating the total economic impact would require consistent information about direct costs, lost revenue, recovery expenses, customer compensation, delayed work, and other consequences across affected organizations. It would also require care to avoid counting the same losses more than once.
A reported estimate may be useful, but it should not be presented as an independently established total without a credible source and a clear methodology.
For the same reason, the claim that hospitals spent $2 billion on workarounds should not be included without a source that specifically supports that figure.
This does not weaken the story.
In fact, it reveals something worth understanding about business risk: the consequences of an outage are not always captured by one immediately available number.
A business may know how much revenue it lost during a shutdown but struggle to calculate the cost of delayed orders, frustrated customers, missed opportunities, and the additional work required to recover.
Those indirect consequences can matter even when no reliable industry-wide total exists.
For business owners, the more useful question is not whether the CrowdStrike incident cost exactly $10 billion globally.
It is whether they understand how a comparable disruption would affect their own operations, and whether they have taken reasonable steps to limit the damage.
The Part of This Story That Matters Most to Your Business
CrowdStrike was not an unknown software provider whose product had suddenly found its way into business operations.
It was an established cybersecurity company whose software was used by organizations around the world.
Businesses had adopted its technology to help protect their systems. The incident was not evidence that every customer had selected an obviously unsuitable product.
It was evidence that even widely used, legitimate software can fail.
That distinction changes how business owners should think about technology risk.
The usual approach to choosing software is to compare features, pricing, security, ease of use, customer support, and compatibility with existing systems.
Those considerations are important. Businesses should still choose products that meet their needs and come from providers they have good reasons to trust.
But there is another question that deserves equal attention:
What happens to the business if this product becomes unavailable?
A business may have selected excellent accounting software, yet have no clear process for handling an urgent transaction when the service is unavailable.
It may have invested in a reliable customer relationship management platform, yet lack a practical way to access essential customer information during an outage.
It may have automated its order processing, but never considered how staff would receive, verify, and fulfil urgent orders if the automation stopped.
These are not necessarily signs of bad software or poor management. They are examples of operational dependencies that can develop gradually as businesses become more efficient.
Over time, the business may become so accustomed to a tool working that the possibility of temporary unavailability receives little attention.
The tool becomes part of the business’s operating foundation.
And the more important that tool becomes, the more important it is to understand what happens when it fails.
The Hidden Vulnerability That Grows as a Business Becomes More Efficient
Efficiency is one of the biggest advantages of modern business software.
A small team can use digital tools to perform work that once required many employees. Orders can be processed automatically. Customer information can be organized in one place. Invoices can be generated with minimal manual effort. Teams can communicate across locations without relying on physical offices.
These improvements allow businesses to grow without necessarily increasing their operating costs at the same rate.
But efficiency can also create dependencies.
Imagine a small company that initially manages customer enquiries through email and a spreadsheet.
As the business grows, it adopts a customer management platform. The team begins recording customer information, tracking conversations, managing follow-ups, and organizing sales opportunities in that platform.
The change makes the business more organized. Employees can find information faster, reduce duplication, and see which opportunities require attention.
Months later, the company has thousands of customer records and an established process for managing its sales pipeline.
The platform is no longer merely a convenience. It has become central to how the company operates.
If the service becomes unavailable, the company may discover that employees do not know which prospects require immediate attention, which customers are waiting for responses, or where important records can be accessed.
The software did not necessarily become less reliable. The business simply became more dependent on it.
That is the hidden vulnerability.
The more a tool improves your efficiency, the more important it becomes to understand the consequences of losing access to it.
The answer is not to avoid automation or return to spreadsheets for every task. It is to make sure that efficiency does not eliminate the business’s ability to respond when normal processes are interrupted.
Why This Is Not Simply a Story About Choosing a Better Vendor
One possible reaction to the CrowdStrike incident is to conclude that businesses should avoid relying on one technology provider.
There are situations where diversification makes sense. But automatically adding more vendors is not a complete solution.
Different tools may depend on the same underlying infrastructure. Two applications may both rely on the same cloud provider, identity system, network, or operating environment. Adding another product can introduce new costs and complexity without necessarily removing the original point of failure.
A better starting point is to understand the business process itself.
Which activities must continue for the company to function? Which systems support those activities? What other systems or services must be available for them to work?
Once those dependencies are understood, the business can decide where additional safeguards are worthwhile.
For one company, that might mean keeping independent backups of important data.
For another, it might mean documenting how to fulfil urgent orders manually.
For a third, it could mean ensuring that an administrator can access recovery instructions without needing to log in to the very platform that has failed.
The right solution depends on the nature of the business, the importance of the affected process, the potential cost of downtime, and the resources available to manage it.
The goal is not to eliminate every possible point of failure. That may be impractical or prohibitively expensive.
The goal is to identify the dependencies that could cause serious disruption and make deliberate decisions about how to manage them.
The Lesson Most Businesses Should Take From the CrowdStrike Outage
The CrowdStrike incident does not prove that every business affected by the outage had failed to prepare. Nor does the available evidence establish that the organizations that recovered fastest all shared the same recovery strategy.
What it does demonstrate is that a technical problem can become an operational problem when essential systems become unavailable.
That is a lesson every business owner can apply without making assumptions about what individual companies did or did not prepare for.
A company may invest heavily in reliable software and still need a plan for temporary unavailability.
It may have a capable IT team and still need clear instructions for employees.
It may have backups and still need to know how to restore them, how long recovery will take, and which activities can continue in the meantime.
Preparation is not simply owning a backup or having an IT department. It means understanding how the business will function when its normal tools are unavailable.
That understanding requires more than a technical checklist.
It requires decisions about priorities, responsibilities, communication, and the minimum level of service the business must maintain during a disruption.
These decisions are easier to make before an incident, when employees have time to consider alternatives and managers can weigh the costs of different options.
During an outage, the same decisions may have to be made under pressure, with incomplete information and customers waiting for answers.
That is why preparation matters.
What Should Your Business Do When Essential Software Fails?
The practical response is not to panic, abandon digital tools, or spend money on every available backup product.
It is to make a few deliberate decisions about the systems that matter most.
1. Identify the software your business cannot easily operate without
Start with the activities your business performs every day.
How do you receive orders? Where do you store customer information? How do employees communicate? How do you process payments? How do you manage appointments, deliveries, inventory, or financial records?
For each activity, identify the software or service that supports it.
Then ask a more important question: if that service became unavailable, which parts of the business would be affected?
Not every application deserves the same level of attention. A tool used occasionally for internal convenience may not require the same recovery arrangements as a system needed to fulfil customer orders or access critical records.
Focus first on the systems whose failure would create the greatest operational consequences.
2. Decide which activities must continue during an outage
A business does not necessarily need every system to remain available at all times.
Some activities can wait a few hours. Others may need to continue immediately.
For example, a marketing report might be postponed until a platform becomes available again. An urgent customer order may require a different response.
Decide which activities are essential, which can be delayed, and how long each can reasonably remain interrupted.
This helps the business avoid treating every technology problem as equally urgent.
It also makes recovery decisions easier because employees understand which activities should receive attention first.
3. Establish a realistic fallback for critical processes
A fallback is an alternative way to perform an essential activity when the normal system is unavailable.
Depending on the business, it might involve an independently accessible copy of essential contact information, a documented manual order process, an alternative communication channel, or a procedure for recording transactions temporarily.
The fallback does not have to reproduce every feature of the normal software.
Its purpose is to help the business maintain essential operations until normal service can be restored.
It must also be practical and secure. For example, storing customer information in an unsecured file or using personal accounts without appropriate safeguards could create additional problems.
The important thing is to identify a workable alternative before it becomes urgently necessary.
4. Know how to recover important data
Having a backup is useful only if the business can access and restore it when needed.
Consider where important data is stored, how frequently it is backed up, who is authorized to restore it, and whether the backup can be accessed independently of the system that has failed.
A backup that depends entirely on the unavailable service may not provide the protection the business expects.
Businesses should also test their restoration procedures periodically. A backup that has never been tested may not work as expected when recovery becomes urgent.
The appropriate approach depends on the sensitivity of the data, the business’s operating requirements, and the resources available to maintain reliable backups.
5. Decide who communicates with customers
A system failure can create uncertainty for customers even when the underlying problem is temporary.
They may not know whether their order was received, whether an appointment is still scheduled, whether a payment went through, or when they should expect a response.
Businesses should decide who is responsible for communicating with customers during a disruption and which alternative channels are available.
Messages should explain what is known, what customers should do, and when another update can be expected, without making promises the business cannot guarantee.
Clear communication cannot eliminate the consequences of an outage. It can, however, reduce confusion and help preserve trust while the business works to restore normal service.
6. Test the plan before depending on it
A written plan can look convincing while containing practical problems.
Employees may not know where the instructions are stored. Contact details may be outdated. A backup process may take longer than expected. The person responsible for recovery may not be available.
Testing helps reveal these weaknesses.
A business can conduct a simple exercise by asking employees to imagine that one critical application is unavailable for several hours. What would they do first? Which tasks could continue? Where would they find the necessary information? Who would make decisions about customer communication?
The purpose is not to predict every possible failure.
It is to discover whether the business has a workable response to a disruption that affects one of its important systems.
The Questions Every Business Owner Should Be Able to Answer
You do not need to be a software engineer to understand your business’s exposure to technology failures.
You need to understand how your operations depend on the tools you use.
Start with these questions:
If your most important software stopped working today, what would happen during the first hour?
Would employees know what to do, or would everyone wait for the system to return?
Could your business continue serving customers for the rest of the day?
Which activities could continue manually, and which would have to stop?
Could you access essential customer and operational information without the affected platform?
If not, what would you need to do to establish an independent recovery method?
Who would be responsible for deciding what happens next?
Would employees know whom to contact, who could authorize an alternative process, and who would communicate with customers?
How would you know when the business was ready to resume normal operations?
Restoring access to one application does not necessarily mean that every process, record, or integration is working correctly.
When did you last test your recovery arrangements?
If the answer is never, you may have a plan on paper without knowing whether it works in practice.
These questions are not designed to make business owners distrust their software. They are designed to help them use technology more responsibly.
A business that can answer them has a clearer understanding of its dependencies and the decisions it may need to make during an outage.
What Small Businesses Can Learn From a Global Technology Failure
It is easy to look at an incident involving millions of computers and conclude that the lesson applies only to large enterprises.
But smaller businesses can be particularly vulnerable to disruptions involving essential software.
A large organization may have dedicated technology teams, formal recovery procedures, and resources for managing unexpected downtime. Smaller companies may have fewer alternatives and rely heavily on a limited number of applications to manage their daily operations.
A small online retailer, for example, may depend on its ecommerce platform for orders, its payment processor for transactions, its inventory software for stock information, and its email service for customer communication.
If one of those services becomes unavailable, the owner may have to manage the technical problem while also handling customer enquiries, supplier communication, and other responsibilities.
That does not mean every small business needs an expensive disaster recovery system.
It means the response should reflect the business’s actual needs.
A small consultancy might only need a secure, independent copy of essential contact information and a clear alternative communication process.
A retailer with a high volume of orders might need a more detailed procedure for tracking transactions and fulfilling orders during downtime.
A business handling sensitive information may need additional safeguards to ensure that its fallback arrangements do not compromise security or privacy.
The right level of preparation is the one that addresses the business’s most important risks without introducing unnecessary complexity.
Preparedness is not about matching the budgets of large companies. It is about understanding what your own business cannot afford to lose access to.
Technology Should Make Your Business Stronger, Not More Fragile
Modern software gives businesses advantages that would have been difficult or expensive to achieve in the past.
Automation reduces repetitive work. Cloud services make information accessible across locations. Customer management tools help teams organize relationships. Digital payment systems simplify transactions. Collaboration platforms allow people to work together without being in the same office.
These are meaningful benefits.
Businesses should continue to adopt useful technology, improve their processes, and take advantage of tools that help them serve customers more effectively.
The lesson from CrowdStrike is not that software should be avoided.
It is that the benefits of technology should be accompanied by an understanding of its limitations.
A reliable product can experience a defect. A trusted service can become unavailable. A routine update can have consequences that were not anticipated.
Those possibilities do not make technology undesirable. They make sensible preparation necessary.
The strongest approach is to choose suitable tools, understand the role they play in the business, protect essential information, and establish reasonable recovery procedures for critical activities.
This allows businesses to benefit from technology without assuming that every system will always work exactly as expected.
The Difference Between a Technical Failure and a Business Crisis
Two businesses can experience the same software outage and face very different operational consequences.
One may lose access to a tool for several hours but continue its most important activities through an alternative process.
Another may find that customer records, internal communication, and essential workflows are all inaccessible at once.
The original technical problem may be similar. The consequences for each business may not be.
That difference is one reason recovery planning deserves attention before an incident occurs.
It is not possible to guarantee that every outage will be brief or that every system can be restored immediately. Nor is it realistic to expect a business to eliminate all technology dependencies.
What businesses can do is identify the systems that matter most, understand the consequences of losing them, and prepare reasonable ways to respond.
The CrowdStrike incident provides a clear example of how a defect in a widely deployed software update can produce consequences across multiple industries.
It also demonstrates why the end of a technical incident does not necessarily mark the end of its operational effects.
For Delta, the outage was followed by days of flight cancellations and recovery work. For affected healthcare organizations, researchers documented disruptions to digital services connected with hospital operations and patient care.
The precise financial consequences varied, and not every organization’s losses can be established from the available evidence.
But the central point does not depend on a single global damage estimate.
A business’s resilience depends not only on the systems it uses, but also on its ability to respond when those systems are unavailable.
This Is Not About Fear. It Is About Readiness.
The CrowdStrike outage was not proof that cybersecurity software is inherently unreliable, that businesses should abandon automation, or that every organization needs an elaborate disaster recovery program.
It was a reminder that modern business operations depend on interconnected technology, and that failures can occur even in systems provided by established companies.
The appropriate response is not to stop trusting technology altogether.
It is to make trust more informed.
Know which systems support your essential activities. Know what information you need to keep accessible. Know which tasks can continue without your normal tools. Know who will make decisions during a disruption and how customers will receive updates.
Then test those arrangements before you need them.
These steps may not prevent every outage. They can, however, help a business respond more deliberately when something goes wrong.
And that is a more useful goal than trying to predict every possible technical failure.
Because the question is not whether a business can guarantee that its software will never fail.
The question is whether the business has thought carefully enough about its operations to know what to do when it does.
The One Question Worth Asking Before Your Next Software Purchase
Before adopting another tool, adding another integration, or moving another essential process onto a digital platform, ask one final question:
If this tool became unavailable tomorrow, would my business know how to continue its most important work?
If the answer is yes, you have taken an important step toward building more resilient operations.
If the answer is no, that does not necessarily mean you have chosen the wrong tool. It means there is an operational question worth addressing before a disruption forces you to answer it under pressure.
The CrowdStrike outage began with a defective software update during a 78-minute window on July 19, 2024. Microsoft estimated that approximately 8.5 million Windows devices were affected. The consequences reached airlines, healthcare organizations, and businesses around the world.
Those figures explain the scale of the event.
The lasting business lesson is simpler: technology can make an operation more efficient, but efficiency alone does not guarantee resilience.
Businesses that understand their dependencies, protect essential information, and prepare practical recovery procedures are better positioned to make informed decisions when normal operations are interrupted.
Do not wait for a system failure to discover how much of your business depends on it.
Join the conversation
Share a useful question or perspective on this article.