How long do outages last?

If you are reading this while waiting for something to come back, the statistically likely answer is: Soon. Outage durations follow a heavily skewed distribution. The great majority of incidents at large services are measured in minutes, a meaningful minority run to an hour or two, and a very small number become the events people still reference years later.

What makes this useful rather than merely reassuring is that the long ones are usually identifiable early, and they share a specific property.

Why most outages are short

Three things have compressed the typical incident dramatically over the last decade.

Automated rollback. A bad deploy that raises the error rate is now frequently reverted by machinery rather than by a human noticing. That turns what used to be a thirty-minute incident into a four-minute one that many users never see.

Traffic shifting. Large services run in multiple regions and can move traffic away from a struggling one. Users experience a brief error window during the shift rather than an outage for the duration of the underlying problem.

Better instrumentation. Time to detection used to dominate time to recovery. Now a meaningful incident pages someone within a minute or two of starting.

The practical effect is that if a large consumer service is still down twenty minutes in, something unusual is happening - Because the normal recovery mechanisms have already had time to work and have not.

The property that makes an outage long

Almost every genuinely long outage shares one characteristic: The thing that broke is also the thing needed to fix it.

When Meta withdrew its BGP routes in 2021, the outage lasted roughly six hours - Not because the mistake was hard to identify, but because the network that carried the fix was the network that had disappeared. Internal tooling, remote access and even physical badge readers depended on it. Engineers ended up travelling to a data centre.

The same pattern recurs in smaller forms. A certificate expires on the deployment pipeline, so you cannot deploy the new certificate. A configuration push breaks the service that distributes configuration. An authentication outage locks out the operators along with the users. Every one of these turns a ten-minute fix into a multi-hour one.

Rough durations by cause

These are patterns from published post-mortems and observed behaviour, not guarantees. Treat them as a sense of scale.

Recovery is not the same as the fix

An important distinction that causes a lot of confusion: The moment the underlying fault is repaired is not the moment the service works.

After a substantial outage, caches are cold. Every request that would normally be served from memory now goes to a database that is simultaneously handling a backlog. Meanwhile every client that has been retrying for an hour reconnects at once - The thundering herd - And re-saturates the system that has just been brought back. Well-run recoveries are therefore staged: Traffic is returned gradually, sometimes region by region, and the service is deliberately kept at reduced capability while caches warm.

This is why a status page can say "resolved" while the app is still visibly struggling, and why the last stretch of a big outage often feels longer than the middle of it.

The really long ones

Multi-day events are rare and almost never a single technical failure. They are what happens when a technical failure meets an operational system that cannot absorb it.

The CrowdStrike incident in July 2024 is the clearest case: The faulty update was withdrawn within about 78 minutes, but recovery required physically touching millions of Windows machines that could no longer boot, and some organisations were still recovering days later. Delta Air Lines took the longest, not because its systems were the most affected but because crew scheduling could not be re-optimised quickly once the schedule had come apart.

Southwest Airlines in December 2022 followed the same shape without any IT failure at the start - Weather disrupted operations, and crew scheduling software could not re-solve the problem, producing ten days of cancellations. Roblox's three-day outage in 2021 was a subtle performance regression in a service discovery layer under sustained load, which is hard to find precisely because nothing has crashed.

The common thread is that the operational recovery, not the technical repair, sets the duration.

What to do while you wait

Genuinely: Not much, and that is the correct answer rather than a resignation. Specifically, avoid the two actions that make things worse.

Do not retry aggressively. Refreshing repeatedly during an outage adds to the load on a system that is already struggling, and for anything involving money it risks duplicate transactions. Payment platforms and transfer networks warn about this explicitly because it is the most common way people turn an inconvenience into a real problem.

Do not start changing your own configuration. Clearing app data, reinstalling, switching DNS servers and resetting network settings during someone else's outage leaves you with a broken local setup to untangle afterwards, and none of it was ever going to help.

Check the provider's status page, check what other people are reporting, and come back later. Status pages have their own quirks that are worth understanding while you have the time.