I subscribed to a Virtual Private Server (VPS) which promises 99.99% of up time guarantee. But I often encounter down time, slow access time and I'm thinking about how to "get them".

Is there anyway/ service that allows me to prove that the web hosting provider isn't delivering the 99.99% up time guarantee?

  • 4
    Good luck with that. Despite there being external monitoring tools, you'd have a hard time claiming back from a flaky provider. Does the uptime % reflect the box, the link to the box, the power to the box, the next tier of box, the backup service, etc. You need to have a good relationship with a reliable supplier for SLAs to "mean" anything in the firstplace. Rackspace offer 100% SLAs that mean nothing, networking between Rackspace VPSs can become laggy and fail with no compensation. Also human error on their side is not reimbursed. Pick someone reliable first then work on SLAs.
    – Metalshark
    Apr 19, 2011 at 4:59
  • 2
    @metalshark, I found this useful. It would get my vote if moved from Comment to Answer!
    – richaux
    Apr 19, 2011 at 8:50
  • 1
    @richaux won't move it to an answer, as I want to see how those who persist with upholding quoted SLAs manage to do it. There is a part of me that wishes it isn't a case of "resolved: won't fix".
    – Metalshark
    Apr 19, 2011 at 16:32

4 Answers 4


The quick answer is that there are companies that monitor websites, pindom being the most well know. for a single site many offer free services. I use http://mon.itor.us theyb have a really nice user interface.

If your website is unresponsive there are many other more likely causes than connectivity issues of your hosting provider. Ideally you should see if they will give you the address of another site on the same node, if both sites are down then you have good cause to blame the host. If only your site is unresponsive then you will need to do your own trouble shooting assuming the VPS is unmanaged.

It's likely that the uptime guarantee refers to network connectivity, normally this is tested by looking for a ping response from your server. Even if you can prove the server was unreachable from multiple locations and that it was the entire node not just your VPS it probably wont be worth it. A typical SLA might offer days service credit per hours down time. Your efforts will be better spent migrating to a more reliable host than "getting" your current one.


I'd say your best bet would be to get a 3rd party monitoring service - similar to Pingdom - to hold them to it. Ideally, having two independently-maintained uptime services to verify any downtime would be pretty difficult for someone to dispute.

Granted, even if you can prove that their 99.99% uptime promise has been broken, that doesn't mean you can get anything out of the company itself. I'd agree with @Metalshark's comment: start out with a reliable host, and that should hopefully make this a moot point.


As the SLA is noramally referenced to the uptime of the server, the best way to check it is at the operating system level.

With the tuptime command you can check how was the behaviour of the last 365 days. Pass to the --tsince option the yearly seconds in negative.

# tuptime --tsince -31536000 
System startups:    5   since   02:26:54 PM 01/10/2017
System shutdowns:   3 ok   -   1 bad
System uptime:      100.0 %   -   364 days, 23 hours, 51 minutes and 39 seconds
System downtime:    0.0 %   -   8 minutes and 21 seconds
System life:        1 year, 0 days, 0 hours, 0 minutes and 0 seconds

Even, the -t option gives you the historic table report since a year ago. Note the "End" column which register how was the shutdown of the system:

# tuptime --tsince -31536000 -t
No.             Startup Date                                          Uptime            Shutdown Date   End                   Downtime

7                               56 days, 18 hours, 25 minutes and 22 seconds   08:52:17 AM 03/08/2017    OK                 23 seconds
8     08:52:40 AM 03/08/2017       2 days, 2 hours, 5 minutes and 10 seconds   10:57:50 AM 03/10/2017    OK                 32 seconds
9     10:58:22 AM 03/10/2017      56 days, 1 hour, 59 minutes and 38 seconds   01:58:00 PM 05/05/2017    OK                  9 seconds
10    01:58:09 PM 05/05/2017   213 days, 11 hours, 28 minutes and 13 seconds   12:26:22 AM 12/05/2017   BAD   7 minutes and 17 seconds
11    12:33:39 AM 12/05/2017    36 days, 13 hours, 53 minutes and 16 seconds

If you want the highest possible precision, adjust in "/etc/cron.d/tuptime" their execution from every five minutes */5 to each minute *.

More information in the repository website: https://github.com/rfrail3/tuptime/

  • In the case above, the uptime is really "99.9984 %" and the downtime "0.0016%" but it's rounded to 2 decimals by default.
    – rfmoz
    Jan 10, 2018 at 14:01

In addition to the above suggestions...

Assuming that you're self-managing the VPS, make sure the problems aren't of your own making or a result of a VPS provisioned with inadequate resources to handle the work you're asking it to do, especially under peak load.

Once you're certain that the problem is upstream of your VPS, if the downtime is frequent, my advice would be to do a well-planned, well-executed move elsewhere rather than engaging in a battle to hold your current provider to their SLA. The SLA probably has more loopholes than a meeting of an old ladies' crocheting club, anyway.

In short, if you're absolutely certain that your downtime and slow performance are the host's fault, I suggest you stop trying to "get them" and get gone instead.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.