UptimeUptime Wiki

Component failure (PSU/Disk/Fan)

Real hardware has pieces that wear out. PSUs hum and quietly die. Disks start throwing read errors. Fans seize up. The good news: you don't lose the host. You lose ONE part. Order a spare, swap it in, and the server carries on. The bad news: a host running with a failed fan or a dying PSU is living dangerously until you fix it.

You can wait for a part to fail and then order one — and eat the downtime plus express shipping — or you can keep compatible spares on the shelf and swap in minutes. At scale, a shelf of spares is the difference between a five-minute swap and a customer-facing outage. Buy ahead of failure, not after it.

Detailed explanation

Per-component health curves

Each host carries component health curves for PSU / Disk / Fan, driven by deterministic wear plus macro-event multipliers (a NAND shortage or a worm can steepen the curve). There are no random death timers — failure is the edge of a curve you can read. When a curve crosses its threshold an edge-triggered ComponentFailed { kind_tag } incident opens.

Resolution consumes a spare

Resolving a ComponentFailed incident consumes a compatible spare from inventory; compatibility is checked against the per-kind ComponentSpec (PsuSpec wattage / form-factor, DiskSpec interface / capacity, FanSpec fit). No matching spare means the host stays degraded until one is ordered and arrives. The open-incidents probe surfaces every live component failure — watch #incidents and keep the spares depth ahead of your fleet's wear front.

On this page