Three outages hit three different companies in the last two weeks, and each one traces back to a safeguard that didn't do its job — one that never existed, one that actively lied about the state of the system, and one that let a bad change through without catching it. None of these are stories about hardware breaking or engineers making an obvious mistake. They're stories about the layer that's supposed to catch failure before a human has to — a different angle than the last Roundup's look at retry logic amplifying failures, but the same instinct: read the postmortem past the headline.
Proton: A Cooling Failure With No Alarm
On the night of August 26 into 27, temperatures in Proton's Frankfurt datacenter went from 21.8°C to 51.9°C in under half an hour — some probes read 60°C. The trigger was mundane: air filters were being replaced on redundant compressors, and the datacenter operator didn't flag the work in advance or communicate the failure promptly once it started. Network cards built to run at 45°C hit 105°C and shut themselves down to survive. Some servers didn't; Proton's own report calls it "heat death," with an unknown effect on the lifespan of the equipment that did survive.
The part worth sitting with isn't the compressor work — maintenance goes wrong sometimes. It's that Proton found out about a cooling failure in its own datacenter the same way its users did: when things had already gone critical. There was no independent, facility-level environmental alerting sitting between "cooling stopped" and "servers are overheating." That gap is now one of Proton's own stated remediation items, alongside accelerating new datacenter capacity already underway.
https://proton.me/blog/august-27-outage-incident-report
Nebius: The Health Check That Lied About Recovery
Nebius's August 19 incident starts the same way Proton's does — a storm knocked out both the cooling system and the building-management system that would normally have alerted on it, so nobody got paged until equipment-level thermal alerts started accumulating almost an hour later. About a third of running virtual machines in the region were interrupted before it was over.
But the more interesting failure happens mid-recovery. At 11:01 UTC, while engineers were still working the incident, an automated health check reported the region as recovered and began routing console traffic back into it — into a data hall that was still overheating. It took seven minutes and a manual intervention at 11:08 to stop it. The mechanism built specifically to protect users from a degraded region instead pointed more of them at it.
Nebius's own published remediation list runs to eleven distinct action items, and one of them reads almost like an apology: "make regional health checks used for global traffic management reflect real service availability, so traffic fails over from an unhealthy region and does not return prematurely." That's exactly the kind of action item we've argued needs a named owner and a date, not just one line in an eleven-item list — a health check that lies once will lie again under the same conditions if nothing forces the fix.
Snowflake: A Config Change That Slipped Past Review
Snowflake's incident is smaller in scope but ran for nearly twelve hours — 00:00 to 11:55 UTC on September 1 — and it's the cleanest example of the third failure mode. An update to the database objects that manage sign-on for Snowflake's CoWork product carried a configuration error. Customers in affected regions across AWS, Azure, and GCP simply couldn't sign in. No other Snowflake feature was touched, and there was no workaround while the fix was rolled out.
This is a routine-change story, not a hardware story — the same pattern we wrote about after August's run of GitHub and Cloudflare outages: a config change that should have been low-risk reached production without whatever validation was supposed to catch a bad value in an auth-critical path. The blast radius stayed contained to one product, which suggests the isolation worked even where the pre-deploy check didn't.
https://status.snowflake.com/incidents/847dlygl25yb
The pattern across all three
Line them up and you get a spectrum, not three unrelated stories: Proton had no safeguard in the loop at all, Nebius had one that actively misfired at the worst possible moment, and Snowflake had one that should have caught a bad change and didn't. Different companies, different systems, same underlying question — not "do we have monitoring/health checks/deploy gates," but "have we actually tested what they do when they're wrong." A safeguard nobody has watched fail is a safeguard you're trusting on faith.