Blog
Perspective

The hourly cost of being offline

Offline Protocol · Jul 8, 2026
perspectivereliability
The hourly cost of being offline

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.

The numbers are already large

The scale is not hypothetical. 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. 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 has put the cost of downtime at roughly $75 million per hour for large enterprises. 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.

Why the default architecture pays this bill

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.

Offline-first is a hedge against the meter

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.

More posts
Engineering · Jul 9, 2026

How DORS failover works

Engineering · Jun 25, 2026

Service discovery without a server