Contabo promised 99.99% last quarter. My monitoring shows 99.947%. That's 27.6 minutes outside SLA. Status page? Green the whole time. Alert fatigue from their "informational" maintenance windows made me tune out actual incidents. I filed ticket #44291 on April 3. Automated response. Escalated May 12. Human appeared June 8, denied claim because "maintenance exclusions apply." Which maintenance? The ones never posted. Has anyone actually gotten money back? What documentation did you need?
Has anyone successfully claimed SLA credits?
Can lah but need fight lor
My company claim from Vultr, 2024. 99.9% promise, get 99.82%. They say force majeure, network upstream issue. Not our fault leh
I log everything already. Screenshot status page, collect MTR, write own incident timeline. 6 month later get 2 month credit. Not worth the time actually. Better spend engineering effort move to better provider
Actually basically I had similar experience with Hetzner, 18 month battle for €340 credit (´・ω・`)
My boss calculate staff time, come to ~$12K. He was so angry basically we continue fighting for principle. In the end they pay but blacklist our account from future SLA claims. Kaomoji cannot express this feeling
Articles are hard sometimes
I think I know this story. Hetzner server in Singapore? I heard from friend, they do this to everyone? Thanks for sharing, make me feel less crazy.
I never bother with SLA credit. Just negotiate lower price upfront. More reliable that way. Cheerful about it now but was angry before
You are measuring availability incorrectly if you want to win this.
SLA credit calculations typically use monthly billing cycle, not quarterly. I think Contabo's standard terms have something about "Unavailable" meaning complete loss of connectivity to all public IP addresses, not latency or packet loss. Worth reading their terms before you do it—there's usually some consecutive minutes threshold before an incident counts, from memory maybe 5 minutes.
RPKI and IRR are irrelevant here, but documentation discipline is. You need:
1. Independent measurement from second vantage point (not your own monitoring)
2. BGP session logs showing prefix withdrawal timestamps
3. Correlation with their published maintenance schedule
Most failures to claim stem from measuring the wrong metric with insufficient evidence. The credits are not mythical. The burden of proof is simply set above what most operators collect routinely.
5-minute minimum? Contabo's terms don't mention that anywhere
Not worth the time actually. Luc agree with chen lor
I re-read the terms. You're right, it's monthly. My 99.947% is quarterly aggregate which means nothing. April was 99.91%, May 99.96%, June 99.97%. So April is the only month that might qualify, and I need to recalculate from their definition not mine.
Their definition of "Unavailable" is indeed complete loss of all public IPv4 and IPv6 connectivity. Not "slow." Not "some packet loss." I had 4-6% packet loss for 20 minutes on April 14, kept pinging, so by their terms that's not an outage at all. I feel stupid now.
Don't. Everyone makes this mistake first time. The SLA is written to be unclaimable, that's the business model.
I keep a spreadsheet now. Columns: month, measured uptime (independent probe), their status page color, whether incident exceeded 5+ minutes of 100% loss, whether maintenance was posted >24h ahead. Most months I never even get to check the last two columns because the independent probe shows 99.99%+ anyway.
The real trick is picking providers whose status page culture matches their SLA terms. Hetzner posts everything. Contabo posts nothing. You can't prove unposted maintenance if you have no logs of what they posted.
Also: RPKI is relevant if you want to prove prefix withdrawal. I mentioned it for a reason. If they drop your prefix and don't re-announce, that's measurable from outside.
Has anyone tried claiming from Contabo's object storage specifically? Their SLA there is 99.9% not 99.99%, and "unavailable" means HTTP 5xx or connection timeout for 30+ seconds on all endpoints. I had a bucket return 503 for 12 minutes in May. Filed claim. Denied because "one endpoint still responded" -- the one in Nuremberg, while Singapore and St. Louis were dead. Their terms say "all endpoints" but support interprets as "any endpoint." Different game entirely.