Most cloud provider evaluations ride on three big factors. Price, the spec sheet, and the uptime figure in the contract. All three matter, and all three are easy to compare in a table. The trouble is that none of them tell you much about the day something fails that nobody scheduled.
Late last month, the Netherlands ran through one of the more extreme stretches of weather the region has seen. A long heatwave pushed the country to a rare heat alert. In fact, it was among the most severe on record, according to scientists quoted by Reuters. Then the heat broke the way it often does, violently. Severe thunderstorms rolled through, and KNMI, the national weather institute, recorded approximately 400,000 lightning discharges over a single weekend, which it called, "an exceptionally high number."
Somewhere in that weekend, among the 60 km/h wind gusts and 5 cm hailstones, lightning struck the building housing one of Servers.com's data centers in Amsterdam and knocked out cooling units serving part of the floor, right as the outside heat was already working everything harder than usual.
This could easily have been a story about what took infrastructure offline, natural disasters can do that.
"Operating infrastructure at this level goes far beyond servers and connectivity. Ultimately, you're contending with physics... heat, weather, hardware. And the physical world doesn't negotiate," said Konstantin Bezruchenko ("BK" for short), Servers.com CTO and co-founder, about the incident.
The reason this is a story about fighting and winning: the failure was not reported to us by the facility, we found it first. Our teams obsessively monitor the equipment we operate, including temperature, separate from whatever the facility watches. When the readings started climbing, that proactive monitoring caught it early enough to matter. We raised the alarm, the cooling was diagnosed and brought back, and customer environments stayed online the entire time, even while equipment ran hotter than it should have for a stretch.
"The fact that we detected the failure before the facility did isn't luck. It's the direct result of standards we consider non-negotiable, even when the rest of the market treats them as extras," BK said.
No honest provider can promise to protect from every natural disaster, but the question you should ask is "what have you already built to notice when natural disasters happen, and how do you work to keep it away from my customers."
That question has a two-part answer: watching closely, and building redundancies.
Watching closely is a habit, not a slogan, and it is not free. Servers.com teams routinely carry out a number of measures that our customers frequently tell us go above and beyond what other providers do. None of it is glamorous, but the physical world fails in ways no contract can anticipate. A lightning strike during a record heatwave is a dramatic version of a very ordinary truth, which is that the gap between a non-event and an outage often comes down to who is watching, and how closely, before anything visibly breaks.
For the thousands of Servers.com customers running everything from enterprise bare metal servers to AI compute, including managed Kubernetes, cloud servers, private cloud environments, and even entire private DCs, in the affected areas of the Amsterdam data center, that operational discipline meant the difference between getting notified that services were down and, instead, never knowing an issue occurred.
Redundancy is the other essential component for workloads that cannot tolerate downtime. In those instances, Servers.com runs more than one data center in the same metro, so a problem in one building does not have to become a customer's problem. In Amsterdam, none of that had to be called on, because the early warning meant it never got that far. The instinct behind both the monitoring and the redundancy is the same. Assume something physical will eventually go wrong on a schedule nobody sends in advance, and build so the answer is already sitting there when it does.
At Servers.com by Nexcess, we run a bare metal specialty cloud for teams whose workloads punish even brief instability: gaming platforms, adtech pipelines, streaming services. For those customers, this was never really a story about a storm. It is a small, concrete example of what proactive has to mean when the thing you are protecting is somebody else's uptime.
Nature does not check anyone's contract before it acts. Our job is obsessively preparing to shield our customers when it does. Can you say the same for your provider?
