Hardware fails early or it fails late. The expensive failures are the early ones — the ones that show up in week three of a production cluster, when the engineer who built it is on another project. Every KEIDIAN node therefore runs a 48-hour burn-in before it ships. It costs us a day per unit. It saves our customers a quarter of their first-year downtime.
What we measure
- Memory: a full patterns-plus-random soak at target clock, repeated twice, with per-DIMM error counters read from the controller — not from the OS, which hides correctable errors until they become uncorrectable.
- Thermals: 100% sustained load on CPUs and GPUs with inlet and outlet logging every 30 seconds. We look for pump curves and fan behaviour, not just peak temperature.
- Storage: a full-device write-verify pass plus a read-back at 24 hours to catch cells that degrade under heat.
- Power: wall-metered draw under load, cross-checked against the PSU’s rated curve — the cheapest early warning of a marginal rail.
The 48-hour profile
Hour 0 is a cold boot and firmware baseline. Hours 1 to 24 alternate memory and storage soaks. Hour 24 is a hard power cycle — the single most effective test for marginal components. Hours 25 to 47 run the thermal profile, and the final hour repeats the hour-0 baseline. If any metric drifts beyond threshold, the unit goes back to the line and the component is swapped, not re-tested and hoped for.
Burn-in does not make hardware better. It makes weak hardware someone else’s problem — before it becomes yours.
What burn-in actually catches
Across our own fleet, the 48-hour soak intercepts defects that would otherwise surface in the first 90 days of operation: marginal DIMMs, a fan bearing that sings after thermal cycling, a NVMe firmware bug that only appears at sustained write temperature. Field data from clusters we shipped with and without burn-in showed a 26% reduction in first-year incidents — which is why the report ships with the machine.
Why we publish the report
Every unit leaves with its burn-in report: the actual measured numbers, not a green checkmark. When a node misbehaves six months later, the baseline is the first thing our support engineers ask for. Customers who run their own fleets use the same reports to calibrate their monitoring thresholds. Transparency here is not marketing — it is the cheapest support ticket prevention we have ever implemented.