Why Ethereum upgrades cause zero downtime.

There is no maintenance window because there is no operator

A normal service upgrades like this: whoever runs it takes it offline, deploys the new version, and brings it back. That works because there is a “whoever.” Ethereum has no operator. It is thousands of independently run nodes agreeing, block by block, on a shared set of rules. Nobody can put up a maintenance page, because nobody owns the switch.

So upgrades cannot work by stopping the network. They work by changing the rules the network follows, at a pre-agreed moment, while it keeps running.

How a hard fork actually ships

A hard fork on Ethereum follows the same shape every time:

• The change is specified and scheduled. The new rules get written up, and an activation point is chosen: historically a block number, and since the move to proof of stake, an epoch. Every client team implements the same specification.
• Node operators upgrade in advance. In the weeks before activation, operators install client versions that know both the old rules and the new ones. Nothing changes yet. The upgraded software keeps following the old rules until the appointed moment.
• The new rules switch on at the activation point. When the chain reaches the scheduled block or epoch, every up-to-date node starts applying the new rules on the very next block. No pause. The block before the fork and the block after it are produced the same twelve seconds apart.

A successful hard fork looks like nothing happening. The head keeps advancing at its usual cadence, the new rules are simply in effect, and the only visible sign is in the changelog.

The Merge: the hard case

The clearest proof is 15 September 2022, when Ethereum switched from proof of work to proof of stake. That is a change to the most fundamental part of how the network agrees on blocks, and it happened on the live chain, with no maintenance window, at zero seconds of downtime.

It worked because the proof-of-stake system had been running in parallel as a separate, heavily tested chain for nearly two years before the two were joined at a pre-agreed point. It was the equivalent of changing an aircraft’s engines mid-flight: rehearsed for a very long time, then executed in a single seamless transition. If that can be done without stopping the chain, an ordinary upgrade certainly can.

What happens if an upgrade goes wrong

Upgrades are where the real risk lives. A bug in a fork is one of the few things that could genuinely threaten liveness, which is exactly why Ethereum forks are conservative: long specification, multiple independent implementations of the same rules, extensive testing on public test networks first, and a scheduled activation everyone has agreed to in advance.

It is also where client diversity earns its keep. Because several independent clients implement each fork, a mistake in one of them shows up as a disagreement to debug, not a single point of failure. That is the difference between a scare and an outage.

The record

Tangerine Whistle and Spurious Dragon in 2016, the Merge in 2022, Dencun in 2024, Pectra in 2025, and every fork in between: all shipped on the live network, and none took it down. A hard fork is now routine enough that most users find out it happened after the fact. That is what a decade of practice at upgrading without an off switch looks like. There is fuller context in the incident history.