When planned becomes unplanned
OVHcloud’s current electrical infrastructure maintenance windows, running through late July 2026, carry an explicit warning in their own status communications: customers “could still experience a temporary reboot or shutdown in the worst case.” Separately, a mandatory patch campaign for CVE-2026-53359, a KVM hypervisor flaw dubbed Januscape, required rolling restarts across tens of thousands of machines, with OVHcloud’s own guidance telling customers that if instances don’t return by the end of the window, try a manual reboot. And in a documented case from their Web Cloud platform, a planned maintenance directly caused a five-day outage affecting the Softcall offering. The root cause entry reads simply: “This incident was caused by this maintenance.”
These are not edge cases. They are the normal mechanics of operating large-scale infrastructure, and they expose a gap that most cloud contracts quietly exploit.
The SLA clause your legal team probably missed
Planned maintenance SLA impact is almost universally zero, because scheduled maintenance is almost universally excluded from downtime calculations. AWS, Azure, GCP, and most other providers exclude maintenance windows from their SLA clocks provided they give advance notice, typically 24 to 72 hours. Some providers restrict maintenance to specific hours; others exclude planned downtime entirely. Either way, the mechanism is the same: a provider can execute a maintenance window that causes real customer-facing outages and remain in full contractual compliance.
When a breach does occur, the remediation is a service credit, typically 10% to 30% of the affected period’s charges, subject to a claim submission deadline. Not compensation proportional to business impact. A four-hour maintenance window that takes your payment processor offline on a Friday evening costs you nothing in credits if the provider gave 48 hours’ notice.
The math compounds quickly once you move beyond a single service. Five dependencies each carrying a 99.9% SLA produce a compounded availability of roughly 99.5%, which translates to more than three hours of cumulative downtime per month rather than the 43 minutes a single-service 99.9% implies. If your recovery time objective is 15 minutes, a 99.9% SLA is structurally incompatible with that target before any maintenance exclusion is applied.
A provider can execute a maintenance window that causes customer-facing downtime and still be in full compliance with its SLA. The contract does not protect against planned maintenance impact; architecture does.
Cloud maintenance window risk is an architecture problem
The instinct is to negotiate better SLA terms. That is the wrong lever. SLA language describes how a provider measures and credits downtime; it does not change the physical reality that a rack reboot, a hypervisor patch, or a network card firmware update will occasionally affect your workload. The only reliable answer is that no single provider maintenance event can reach your production traffic.
That requires three things working together: workload distribution across independent failure domains, network paths that do not share a common upstream, and a failover mechanism that does not depend on DNS TTL expiry or manual intervention.
What zero-downtime maintenance architecture actually requires
Independent failure domains
Availability zones within a single provider’s region are not independent failure domains for maintenance purposes. A provider-wide KVM patch campaign, an electrical infrastructure maintenance affecting multiple racks, or a control plane upgrade touches all zones simultaneously. Genuine independence means separate providers, separate physical facilities, or both. For European workloads, this means distributing across geographically distinct sites with no shared management plane.
BGP multihoming as the network foundation
BGP multihoming connects your infrastructure to multiple upstream providers and announces your own IP prefix, typically a provider-independent /24 IPv4 or /48 IPv6 block, via your own Autonomous System Number. When one path degrades or a provider maintenance event pulls a route, BGP withdraws the affected path and traffic shifts to the surviving upstream automatically. No manual changes, no DNS TTL to wait out.
Pairing BGP with Bidirectional Forwarding Detection (BFD) tightens this further. BFD runs millisecond-level heartbeats at the forwarding plane and signals BGP to tear down sessions immediately on failure, yielding sub-second reconvergence in well-tuned networks. The difference between a 30-second BGP holddown timer and a sub-second BFD-triggered failover is the difference between a noticeable blip and a transparent one.
We run BGP multihoming across 44 points of presence in Europe and the Middle East, with direct peering to AWS, Azure, GCP, Oracle, and Cloudflare at every site. That peering density means traffic destined for a hyperscaler workload during a failover event does not traverse unpredictable public transit paths; it exits through a known, low-latency interconnect regardless of which site is carrying the load.
Proof-of-concept validation before you need it
A zero-downtime maintenance architecture is only as good as the last time someone tested it. The proof-of-concept framework for validating cloud resilience during upgrades is straightforward in principle and consistently skipped in practice.
- Simulate the maintenance event: Take one site or one upstream path offline deliberately, during a planned test window, and confirm that traffic shifts cleanly and that your monitoring catches the transition.
- Measure actual recovery, not theoretical RTO: Record the time from path withdrawal to full traffic restoration. Compare it to your stated RTO. If they do not match, the architecture needs adjustment, not the RTO document.
- Validate at the application layer: SLA measurement typically happens at the infrastructure layer. Your customers experience the application layer. Confirm that a BGP failover does not surface as a session drop, a failed transaction, or a cache miss that cascades into a database overload.
- Test the maintenance notification lag: Providers give 24 to 72 hours’ notice. Run a drill where your team receives a simulated maintenance notice and executes the failover procedure within that window. The procedure should be documented, rehearsed, and not dependent on specific individuals.
What the OVH situation actually tells you
The July 2026 OVHcloud maintenance sequence is not evidence that OVHcloud is unusually unreliable. StatusGator has recorded more than 2,685 outages affecting OVHcloud users over five-plus years of monitoring, which is consistent with operating infrastructure at scale. The more instructive detail is the Januscape patch campaign: a security vulnerability requiring urgent remediation across tens of thousands of machines, with a maintenance window that could not be deferred and that carried explicit reboot risk. That scenario, a security-driven forced maintenance with broad impact, can happen to any provider. The question is whether your architecture absorbs it or inherits it.
Cloud provider maintenance downtime is not a provider quality problem you can contract your way out of. It is a distributed systems problem you solve with redundant paths, independent failure domains, and a failover mechanism you have actually tested. The SLA tells you what credit you receive after the fact. The architecture determines whether there is anything to credit.
