- Convert every uptime percentage into minutes per month. 99.9% is 43 minutes; 99.99% is about 4.
- Response time is when someone replies. Resolution time is when it is fixed. Most agreements only commit to the first.
- RPO is how much data you can lose; RTO is how long you are down. Ask for both as numbers, not adjectives.
- Read the exclusions before the promises. Scheduled maintenance is usually excluded from the uptime figure entirely.
- A service credit refunds a fraction of your hosting fee, never your lost revenue. It is a signal of confidence, not compensation.
What does an uptime percentage actually promise?
Very little until you convert it into time. The difference between 99.9% and 99.99% sounds like a rounding error and is the difference between three quarters of an hour of downtime a month and about four minutes. Do the conversion for every figure you are quoted, because that is the only form in which they can be compared.
| Uptime | Per month | Per year | In practice |
|---|---|---|---|
| 99% | 7h 18m | 3d 15h | A working day of downtime a year |
| 99.5% | 3h 39m | 1d 20h | Noticeable to regular visitors |
| 99.9% | 43m | 8h 46m | The common shared-hosting figure |
| 99.95% | 22m | 4h 23m | Better managed hosting |
| 99.99% | 4m 23s | 52m | Genuinely high availability |
| 99.999% | 26s | 5m 15s | Rare outside large infrastructure providers |
Two decimal places is where the number starts to mean something. Anything at 99% is a very low bar.
Ask what "up" means, and who measures it
Some agreements count the server as available if it responds to a ping, which it will do perfectly while your site returns a 500 error to every visitor. Others measure a full page load. And if the provider measures from inside their own network, the check never traverses the path your visitors use. Ask what is checked, from where, and how often.
The measurement question is the one that separates a meaningful commitment from a marketing figure. A check every five minutes can miss a four-minute outage entirely. A check from a single location cannot tell you whether visitors in another country could reach you. We commit to 99.99% and measure every minute from outside our own network, which is the only vantage point that reflects what a visitor experiences. See our SLA and the status page.
What is excluded from the uptime figure?
Read this section before the headline percentage. Exclusions determine what the number covers, and a generous-looking figure with broad exclusions can commit a provider to less than a modest one with narrow exclusions.
| Common exclusion | Reasonable? | What to ask |
|---|---|---|
| Scheduled maintenance | Yes, with limits | How much notice, and is there a cap per month? |
| Your own code or plugins | Yes | Who decides, and how is it evidenced? |
| DDoS and attacks | Sometimes | Is mitigation included, or excluded as force majeure? |
| Third-party network failures | Partly | Their upstream provider is still their supplier |
| DNS not under their control | Yes | Fair if you host DNS elsewhere |
| Anything caused by "emergency maintenance" | No | Undefined and unlimited. Ask for a definition |
The last row is the one to negotiate. Without a definition it can absorb any outage after the fact.
Excluded maintenance is still downtime to your customers
A visitor who cannot check out at 2am does not care that the window was announced. If maintenance is excluded from the figure, ask how many hours per month are permitted, how much notice you get, and whether you can choose the window for your own site.
- How much notice for planned maintenance? Seven days is reasonable; twenty-four hours is not, for anything that takes the site offline.
- Is there a monthly cap on excluded maintenance? Without one, the exclusion has no boundary.
- Who declares an outage? If only the provider can, and you have to claim within a short window, the burden is entirely on you.
- Is there a public status page with history? A provider that publishes past incidents is one that expects to be held to them.
How do I read support response times?
The critical distinction is response versus resolution. Response time is how long until a human replies. Resolution time is how long until the problem is fixed. Almost every agreement commits to the first and says nothing about the second, which is understandable but worth knowing before you rely on it.
| Term | Means | Watch for |
|---|---|---|
| First response time | Someone acknowledges the ticket | An automated reply that satisfies the clock |
| Resolution time | The problem is actually fixed | Rarely committed to. Ask if it is |
| Business hours | Their office hours, in their timezone | Which timezone, and which public holidays |
| 24/7 support | Someone is reachable at any hour | Reachable by whom, and can they act or only escalate? |
| Priority levels | How the ticket is classified | Who classifies it, you or them? |
Rows four and five decide whether 24/7 support means an engineer or a night-shift inbox.
- Ask who answers out of hours. An engineer who can restart a service is a different service from someone who logs the ticket for the morning.
- Ask who sets the priority. If the provider classifies your total outage as normal priority, the emergency response time never applies.
- Ask what happens on a UK bank holiday. "Business hours" over a long weekend can mean four days.
- Ask for the escalation path in writing. The useful part of a support agreement is what happens when the first reply does not fix it.
Test it before you need it
Open a moderately technical pre-sales question and see how long a real answer takes, and whether it comes from someone who understands the platform. That single test tells you more about what an incident will feel like than any published response time.
What do RPO and RTO mean for backups?
Two numbers describe any recovery promise. RPO, Recovery Point Objective, is how much data you can lose: the gap between the last usable backup and the failure. RTO, Recovery Time Objective, is how long you are down while it is restored. Get both as numbers. Adjectives like "regular backups" commit a provider to nothing.
| Backup frequency | Worst-case data loss (RPO) | Suits |
|---|---|---|
| Weekly | 7 days | Nothing you would miss |
| Daily | 24 hours | Brochure sites, low-frequency content |
| Every 6 hours | 6 hours | Active content sites |
| Hourly | 1 hour | Busy sites and small shops |
| Continuous replication | Seconds | Transactional systems |
For a shop, ask what a day of lost orders is worth, then compare that with the cost of more frequent backups.
- 1How often are backups taken, and how long are they kept? Daily for thirty days is a common and reasonable answer.
- 2Are they held somewhere separate? A backup on the same server, or in the same data centre, does not survive the events that matter most.
- 3Are they tested? An untested backup is an assumption. Ask whether restores are verified automatically, and how often.
- 4How long does a restore take, and who runs it? Self-service in minutes and a support ticket in hours are very different services.
- 5Can you restore one file or one table? Full-site-only restore means a small mistake costs you every change since the backup.
"We take backups" is not a recovery plan
The failure everyone eventually meets is a backup that has been running for months and cannot be restored: a corrupt archive, a missing database, an incomplete file set. Nobody finds out until the day it matters. Ask specifically whether restores are tested, and what happens when a test fails.
This is why we restore-test every nightly backup automatically rather than only writing it. A backup that has been proven to restore is the only kind worth counting on. See how our backups work and our backup strategy guide for how to think about your own retention.
Are service credits worth anything?
As compensation, no. A service credit typically refunds a percentage of one month's hosting fee, which on a small plan is a few pounds. If four hours of downtime costs a shop several thousand pounds in orders, a credit does not begin to touch it. Its real value is as a signal: a provider willing to put money behind a number is one that expects to hit it.
| Question | Why it matters |
|---|---|
| Is the credit automatic or claimed? | A claims process with a short window means most credits are never paid |
| What is the claim deadline? | Some require notice within days of the incident |
| What is the maximum? | Usually capped at one month's fee, whatever the impact |
| Credit or cash? | Credit only helps if you are staying |
| Does using it waive other remedies? | Some agreements make the credit your only remedy |
The last row is the one worth reading twice on any contract of significant value.
How we handle this
On self-serve plans we commit to 99.99% uptime backed by per-minute monitoring and a 30-day money-back guarantee, rather than a service-credit table that would return a few pounds. Hand-sold Enterprise agreements can carry a bespoke written SLA with agreed credits, set per contract. See our SLA or talk to us about Enterprise.
- 1Convert every percentage into minutes per month. Compare like with like.
- 2Read the exclusions first, then the headline figure in that light.
- 3Separate response from resolution, and find out who answers out of hours.
- 4Get RPO and RTO as numbers, and ask whether restores are tested.
- 5Check there is a public status page with incident history. It is the cheapest possible evidence of how a provider behaves during a bad week.
- 6Test support before you commit, with a question that requires a real answer.
The other half of reliability is what you can see yourself. A provider's status page tells you when they know something is wrong; your own monitoring tells you when your site is wrong for reasons they will never page on. Checking CPU, memory and disk usage and reading system logs cover the server side of that.
Frequently asked questions
How much downtime does 99.9% uptime allow?
About 43 minutes a month, or 8 hours 46 minutes a year. 99.99% allows roughly 4 minutes 23 seconds a month. Always convert a percentage into minutes before comparing providers, because the decimal places hide an order-of-magnitude difference.
What is the difference between response time and resolution time?
Response time is how long until someone replies to your ticket. Resolution time is how long until the problem is fixed. Nearly every agreement commits only to response, so a one-hour response time says nothing about how long you will be down.
What do RPO and RTO mean?
RPO, Recovery Point Objective, is the maximum data loss you would accept, which is set by how often backups run. RTO, Recovery Time Objective, is how long recovery takes. Daily backups mean an RPO of 24 hours: everything since the last one is gone.
Are hosting service credits worth claiming?
Financially, rarely: they refund a fraction of one month's fee, capped well below the actual cost to the business, and many require a claim within days. Their value is as a signal of confidence. Check whether accepting one waives your other remedies, which some contracts specify.
What should I check before signing a hosting SLA?
The uptime figure converted into minutes, what counts as "up" and who measures it, the exclusions, response versus resolution commitments, out-of-hours coverage, RPO and RTO with tested restores, and whether there is a public status page with incident history.
Is scheduled maintenance counted as downtime?
Usually not: most agreements exclude announced maintenance windows from the uptime calculation entirely. Ask how much notice you get, whether there is a monthly cap on those hours, and how "emergency maintenance" is defined, since an undefined term can absorb any outage after the fact.
About G7Cloud Engineering
Articles written by the engineers who build and run G7Cloud: UK managed hosting and the AI Website Builder. We write about what we operate every day: containers, backups, databases, and the small-business websites that run on them.
More about G7Cloud →
