IT Outage Lessons: Business Continuity Planning Guide

On Saturday, July 18, 2026, gate agents at Newark, Chicago O'Hare and San Francisco pulled out paper boarding passes and started checking in passengers by hand. The United Airlines technology outage had just knocked out the reservation system behind check-in, boarding and bag drop nationwide. For roughly 75 minutes, one of the largest carriers in the country ran on manual workarounds.

What Happened in the United Airlines Technology Outage

The first reports came in around 7:40 a.m. Eastern. By 8:23 a.m., Down Detector had logged more than 430 complaints from travelers stuck at check-in counters and gates.

United Airlines confirmed the cause: a fault in SHARES, the reservation platform that processes check-in, prints boarding passes and coordinates bag drop. Contact centers went down too, so travelers calling for help faced long holds.

Airports from Washington Dulles and Newark to Houston's Bush Airport and cities across the country felt the impact. Staff at some locations switched to manual check-in to keep lines moving.

The outage lasted about an hour and fifteen minutes. Flights already in the air were never affected; the failure was strictly a ground-operations problem. By early afternoon United said operations were back to normal, but the pattern it exposed is one every management team should study before a similar failure hits their own systems.

The SHARES System: A Legacy Backbone That Keeps Breaking

SHARES is a legacy system, built long before cloud infrastructure was the default and running as United's reservation backbone for years. Modernizing a platform that touches every check-in counter and gate is a slow, careful project, not a weekend sprint.

In February 2026, United executed exactly that kind of careful project. Over an overnight window, the airline moved SHARES data from a data center in North Carolina to cloud infrastructure in Chicago. The team rehearsed the migration in advance and paused bookings for about three and a half hours, canceling roughly 600 flights in the process.

That planned cutover went smoothly. Five months later, the same system failed anyway, this time with no warning and no rehearsal. It was also United's second major technology disruption in about a year, after a separate outage grounded departures in August 2025.

Why Ground Operations Are the Blind Spot in Continuity Planning

Most continuity plans focus on the dramatic scenario: a plant fire, a data breach, a full network shutdown. Fewer plans war-game what happens when a single reservation or check-in system goes dark while everything else keeps running.

That is exactly what happened on July 18. Aircraft, pilots and air traffic control were unaffected; the failure sat entirely in ground operations: check-in kiosks, boarding scanners, bag tags and contact centers. Those are the systems that touch customers first, and they are often the last ones covered in a disaster recovery plan.

Any business with a customer-facing operations layer, retail checkout, appointment booking, order fulfillment, has the same exposure. The core product can be fine while the system that delivers it to the customer fails completely.

A system does not have to be down everywhere to shut a business down somewhere.

Crisis Communication Lessons From United's Response

United posted a public update within hours, acknowledging the outage and confirming operations were returning to normal. The statement did not explain the root cause in detail, but it was fast, clear and visible on the channels travelers were already checking.

That speed mattered more than a polished explanation. In a crisis, silence reads as loss of control even when a team is actually making progress behind the scenes. Leaders who own a collaborative decision-making process ahead of time can approve and publish that first statement in minutes, not hours.

Manual fallback also did real work here. Gate agents who could still check in passengers by hand kept some flights on schedule while engineers worked the fix. That kind of fallback only works when a team already practices deliberate time management around risk reviews, instead of improvising after the fact.

Building a Business Continuity Plan That Survives Legacy System Failure

Four practices separate teams that recover fast from teams that freeze:

• Map the ground layer, not just the core system. List every customer-facing process that depends on a single platform: check-in, checkout, scheduling, support. Treat each one as its own point of failure.
• Test unplanned failure, not just planned maintenance. A rehearsed migration proves a team can execute a plan. It does not prove the system survives an unannounced fault five months later.
• Keep a manual fallback current. Paper processes, offline checklists and trained staff are not old-fashioned, they are the layer that keeps revenue moving when software cannot.
• Pre-approve the first public statement. Draft the structure of a crisis update in advance so a clear decision-making process can get it published within the first hour.

None of this requires predicting the exact failure. It requires accepting that a legacy system a business has already modernized once can still fail again, and building the response muscle for that reality now. The FEMA business continuity guidance at Ready.gov recommends exactly this kind of unplanned-failure testing, not just rehearsed maintenance windows.

Leaders who treat this kind of event as a one-off news story miss the pattern. The conceptual skills that let a manager see a legacy dependency as a systemic risk, not an IT department problem, are what separate teams that adapt fast from teams that scramble every time.

Frequently Asked Questions

Related guides