← All security newsOutage

The CrowdStrike outage of July 2024, explained for small teams

A faulty update crashed millions of Windows machines in July 2024. It wasn't a hack, and the lessons on releases and rollbacks apply to any team.

By the Dignite Studios team · Nov 5, 2026 · 7 min read
A blue error screen at the centre of a network of servers, with a severed orange connection

Early on Friday 19 July 2024, people around the world started seeing the same thing: a blue screen, a restart, another blue screen. Airport departure boards went dark. Hospitals postponed procedures. Shops couldn't take card payments. Nobody had been hacked. A security company had sent out an update and, in doing so, broke the computers it was meant to protect.

What happened, in plain English

CrowdStrike makes security software called Falcon, which runs deep inside Windows so it can spot threats. To keep up with new threats, it regularly sends out small data updates, which it calls content updates. One of these, for a component known as a channel file, contained data that the software wasn't prepared for.

CrowdStrike's later review described a mismatch in the number of values the update supplied compared with what the code expected. Because Falcon runs at such a low level, the mistake didn't just crash the program. It crashed Windows itself, and the machines then crashed again every time they restarted.

Microsoft estimated that about 8.5 million Windows devices were affected. That's a small share of all Windows machines, but they were concentrated in places where downtime hurts: airlines, banks, healthcare and retail.

The fix was simple on paper and miserable in practice. Someone had to start each affected machine in a recovery mode and delete one file. With thousands of computers, many of them in locked-down or remote locations, that took days.

Why it's relevant even if you've never heard of Falcon

The root problem wasn't unusual software. It was a familiar shape: a change that reached everyone at once, with no easy way back. You can build exactly that on a much smaller scale without noticing.

  • A deploy on a Friday afternoon that changes the checkout and goes live to every customer immediately.
  • A plugin or library auto-update that quietly breaks the contact form.
  • An expired certificate or domain that takes the whole site down overnight.
  • A third-party service you depend on changing something without warning.

The effect on your customers is the same: they can't buy, book or log in, and they don't care whose fault it was.

What to put in place

Release to a few people first

Roll changes out to a small share of users or a test group, watch what happens, then widen. CrowdStrike committed to staged rollouts after the incident, which tells you how valuable the idea is. Even a simple version helps: ship to a staging copy, click through the main flows, then go live.

Have a rollback you've actually tried

"We can roll back" is only true if someone has done it recently. Practise once on a quiet afternoon. Note how long it takes and what breaks.

Watch the flows that make you money

Server uptime isn't enough. A site can be "up" while the checkout button does nothing. Set up a simple check that goes through sign-up or checkout on a schedule and alerts you when it fails.

Know your dependencies

List the outside services and software your business can't run without, and for each one, ask what you'd do if it failed for a day. Sometimes the answer is "nothing", and that's worth knowing before it happens.

Decide how you'd tell customers

A short, honest status message posted quickly beats silence. Have a place to put it, and a person responsible for writing it.

The takeaway

Outages are rarely caused by anything exotic. They tend to come from ordinary changes made without a safety net. If you'd like to see how your own site behaves on real phones and browsers, and where it might trip customers up, that's what our audit looks at. Our security checklist covers the backups and recovery side.

Common questions

Was the CrowdStrike outage a cyberattack?

No. It was caused by a faulty content update that CrowdStrike pushed to its own security software. There was no attacker involved.

Could something like this happen to a small business?

Yes, on a smaller scale. A bad deploy, a broken dependency update or an expired certificate can stop your sign-ups or checkout just as effectively, and often for longer because nobody is watching.

What's the cheapest protection against a bad release?

Release to a small slice of users first, watch your key flows, and keep a rollback you've actually tested. None of that needs an enterprise budget.

Not sure if your app has this problem?

Our $79 audit checks for issues like this and ranks what to fix first. No issues found? Full refund.

Get my audit · $79