The hourly cost of being offline

TL;DR

Downtime is better measured in dollars per hour, because cost decides whether anyone acts, and published outage figures are already large. Systems that treat connectivity as binary go fully down at the edge. Offline-first devices keep coordinating locally and reconcile when connectivity returns.

Downtime is usually measured in hours. That is the wrong unit. Hours describe how long something was broken, but they do not describe what it cost, and cost is what decides whether anyone does something about it.

The more useful unit is dollars per hour, because it reframes offline-first from a nice-to-have into a line item you can defend. Priced per hour, an outage becomes a cost a business can weigh against the engineering it takes to keep working through one.

Cost of internet shutdowns and outages

Access Now recorded 313 internet shutdowns in a single year, a record. Blackouts drove an estimated $19.7 billion in losses. Surfshark’s tally put 4.62 billion people in regions affected by a connectivity disruption. The scale is not hypothetical. These are not edge cases at the edge, they are a trend line, and the trend points the wrong way.

Zoom in from the global figure to a single operation and the number sharpens. Forbes reported estimates of roughly $75 million lost per hour by the businesses hit by the October 2025 AWS outage. Whatever the exact figure for any given business, the shape holds: the meter runs continuously while the network is gone, and it does not care why the network left.

Outage cost in cloud-dependent architecture

Most systems are built on an assumption that quietly runs through every diagram: the network is there. There is an arrow to “cloud,” and the arrow is presumed to hold. In an office or a data center, it mostly does. At the edge, where the work is on a factory floor, a delivery route, a remote site, or a payment terminal, it does not, and the moment that arrow breaks, the application does too. The device is not slow or degraded, it is simply down, and the per-hour meter starts.

The reason is that connectivity is usually treated as binary. You are online or you are not, and the code has no plan for the second state. So an outage that should be a local inconvenience becomes a full stop, and the dollars-per-hour figure attaches to problems that never needed a live link in the first place.

Reducing downtime cost with offline-first architecture

The alternative is not to prevent outages, which no one can, but to make them cheap. If devices can keep discovering each other, coordinating, and moving data among themselves when the backhaul is gone, then the outage stops being a full stop. Work continues locally, state reconciles when connectivity returns, and the per-hour meter runs a lot slower because the operation did not actually stop.

That is the whole case for building offline-first, and it is why the dollars-per-hour framing matters more than the hours one. Hours tell you the outage happened. Dollars per hour tell you what it was worth to have designed for it in advance. When the figure sits at millions per hour for a large enterprise, the engineering to keep working through a disruption is not an insurance premium you hope never pays out. It is a hedge against a meter that, industry-wide, is already running.

The teams that treat connectivity as a portfolio rather than a switch are not chasing a rare failure. They are declining to pay a bill that the numbers say is coming.