How a Small Host Actually Keeps a Server Up (and What Breaks)

Why an uptime percentage tells you almost nothing

A published availability figure is usually a marketing number: unaudited, self-measured, and with no stated method for what counts as downtime. Two hosts can quote the same figure and have completely different recovery capabilities.

What actually predicts availability is the answer to a narrower question: when the site loses power or connectivity and nobody is there, what specifically happens next? That answer is concrete and checkable. A percentage is not.

The failure modes, and which ones are recoverable remotely

The last two rows are where availability is actually won or lost, and they are the two rows most providers never discuss.

What we run

• A management line that carries no customer traffic, so the rescue path does not share a failure domain with the thing being rescued.
• An out-of-band KVM wired directly to the host — console access and firmware-level control, not an agent that needs the OS to be alive.
• A switched outlet on the host's power circuit, for the case where the machine needs a hard power cycle.
• Power-on-after-loss set in firmware, so the host comes back by itself when power returns.
• A UPS, so short interruptions never become a reboot at all.

This is a one-time cost that does not scale with customer count, which is the whole argument for it. Sending a person scales linearly and eventually consumes the margin.

Two failures this did not cover

Both are more instructive than the equipment list, so we publish them.

2026-07-26 — the rescue path depended on the thing being rescued. Our control-plane tunnel egressed from behind the router it existed to manage. The router went down, and with it the ability to reach the box that would have fixed the router. A deadlock, and entirely self-inflicted. The rule we took away: a rescue path must never share a dependency with its target. The control plane now defaults to the management line.

2026-08-07 — the failure mode we prepared for was not the one we got. A carrier technician converted our lines from DHCP to static configuration. Our equipment was still configured for DHCP and dropped off one by one as leases expired, including the management line. We had planned for 'the out-of-band router hangs, power-cycle it'. What happened was 'it is alive and healthy, but its uplink has no valid configuration', and a switched outlet is useless against that. Recovery came through the one line that had stayed on DHCP: power-cycling its modem gave the management router a valid address again, and the rest was done remotely — at the cost of a full day offline.

The fix that follows from the second one is observability, not more hardware: every line now carries its own probe in our monitoring, so 'alive but without a valid configuration' is a state we can see rather than infer. The residual gap — the uplink itself as the casualty — is real, and we would rather say so than imply it does not exist.

What to ask any provider

1. Does out-of-band management run on a line separate from customer traffic? A shared line means the rescue path dies with the outage.
2. What happens when the host itself stops responding — is there console and firmware access, or only an agent inside the operating system?
3. Does the machine come back on its own after a power loss, or does someone have to press something?
4. What was your last outage, and what actually fixed it? A provider who cannot answer specifically either has not had one or does not track them; both are worth knowing.
5. Which failure modes are you not covered for right now? An honest answer here is worth more than any percentage.

We answer all five above. What we claim is that most failures drop to remote recovery in minutes — not that a site visit never happens, which no one operating in an ordinary building can honestly promise.