Be honest. We all lie on RFPs. I say we need five nines. We budget for three. We architect for two. Reality? Scheduled maintenance eats the SLA before we even talk about actual outages. Whats your real number versus your invoice number
How many 'nines' do you actually need versus pay for?
Heres my real numbers
- Contabo: pay for 99.99%, got 99.1% last quarter (3 hr outage, "network maintenance")
- OVHcloud: pay for 99.9%, got 99.97% (overdelivering, suspicious)
- Vultr "cheap" unlimited plan: 97.2% but $2/GB so who cares
- Hetzner: pay for 99.99%, actual 99.99% but virtualization tax is 40% performance hit
Honestly I design everything for one nine and use geographic redundancy for anything that matters
52 boxes, maybe 6 are actually critical
Caramba, five nines for my things!! Nossa!!
I pay for 99.999% but my application is cat photos kkkkk
Is not critical but my boss dont know this, he thinks is very important
Kkkkkk the monitoring page is very beautiful with green, this is what he looks, not the SLA
I think real need is 99% but we pay 99.99% because "enterprise"
@beto60 can you share your monitoring dashboard? I want to make beautiful also lah, my boss same same hahaha
For me I pay for 99.99% at InterServer but reality is maybe 99.5%? They say "excluded downtime" for planned maintenance, thank you. But how can maintenance be excluded if I cannot access my server during that time?
I think we pay for five nines but design for two nines also. Thank you for honest poll.
The virtualization tax makes these numbers meaningless without context.
OpenVZ "99.99%" = host kernel panic takes everyone down. KVM with proper cgroup limits = actual isolation but lower density so provider pushes you to "cloud" (OpenVZ with marketing).
I measure by:
- unplanned downtime per VM
- time to live migrate
- kernel panic frequency on host
No SLA covers the virtualization tax. You pay for it in unpredictable latency spikes.
---
- honest answers:
- designed for: 99.9%
- paid for: 99.99%
- reality: 99.7%
- NOTE: "planned maintenance" excluded per clause 7.3
- WARNING: clause 7.3 is 40% of calendar year
- one provider:
- promised: 99.999%
- delivered: 99.95%
- compensation: account credit
- NOTE: credit expires in 30 days
- NOTE: minimum usage $500/month to apply
---
99.95% with that many exclusions? I smell a clause game
Not a game. A sport. Olympic level.
Provider is not in your list, is local Ukrainian company. I will not name because they sue customers for reviews. True story from friend.
My clause 7.3 calculation: 40% of year = 146 days. But "planned maintenance" is only nights 02:00-06:00. So 146 days becomes 584 hours. Still, they schedule 3-4x per week.
I keep spreadsheet. 2024 total "excluded" downtime: 127 hours. Planned. Like weather is planned.
This is why I measure host kernel panics, not SLA. My current count for 2024:
- Hetzner Cloud (Falkenstein): 0 host panics, 2 live migrate failures
- Contabo (Nuremberg): 1 host panic, 6 hour recovery, no explanation
- OVHcloud (Gravelines): 1 host panic, 45 minute recovery, automatic ticket
OVHcloud Gravelines fire was 2021, but they learned. Contabo learned nothing. "Network maintenance" is their answer for everything.
The virtualization tax is real. I benchmarked same workload on Hetzner CPX11 vs Contabo VPS S: Contabo claims more cores, delivers 40% less throughput because neighbor is mining Monero. Not their problem per SLA.
Oh this explains my Nuremberg box. Load average 12 on 4 "cores" at 3 AM. I thought it was backups.
I moved the mining-adjacent workload to dedicated at Hetzner auction. 34 EUR, old Xeon, no neighbors. 99.99% measured myself, because only one tenant to blame.
Auction hardware is the honest SLA. You get what you get and you know exactly what that is. I used https://www.hetzner.com/sb for that.