Hosting SLA Explained: Uptime, Downtime, and Maintenance for UK Businesses

The hosting SLA is the part of your contract that specifies how long your website or system can be offline before the provider owes you compensation. It might seem like a minor legal detail, but it's what determines whether a Tuesday afternoon outage results in credit, a penalty, or just an email apology. In this guide, I'll explain uptime, SLAs, and maintenance windows in plain English, with real figures and the fine print that most often catches customers out.

TL;DR

• 99.9% uptime allows for approximately 43 minutes of downtime per month. 99.5% allows for 3 hours and 36 minutes. The difference a single 'nine' makes is enormous.
• A hosting SLA almost never covers your losses: it returns a percentage of the monthly fee as credit. On AWS, an EC2 instance falling below 99.5% yields a 10% credit.
• Scheduled maintenance is usually excluded from uptime calculations. Read how the contract defines the window and how much advance notice is given.
• A system relies on multiple services. Three components each with 99.9% availability in series deliver approximately 99.7% overall.
• Beyond the percentage, what matters most are the response time, resolution time, and backup restoration time written in the contract.

What a Hosting SLA Is (and Isn't)

SLA stands for Service Level Agreement. In a hosting SLA, the contract formalises three things: what metric the provider promises (typically monthly uptime), how that metric is measured, and what happens when it's not met.

In the day-to-day operations of a server, three acronyms often appear together:

• SLI (indicator): The actual measured number. Example: the website responded to 99.94% of checks this month.
• SLO (objective): The team's internal target. Example: we aim for 99.95%.
• SLA (agreement): The contractual promise, usually more lenient than the SLO, because failing to meet it costs money.

Uptime and Availability Aren't Exactly the Same Thing

Uptime is the percentage of time the service was online. Availability, in the strictest sense, is the percentage of time it was usable for the user. A server can be powered on, with its ping responding, while the database has crashed and the page returns a 500 error. For the infrastructure provider, this might count as uptime. For your customer, the website is down.

That's why the first question when reading a hosting SLA is: what exactly is being measured? The server? The network? The HTTP response of your application?

An SLA Isn't a Guarantee Against Downtime

This is the most common misconception about hosting SLAs in contracts for small and medium-sized businesses. A 99.9% hosting SLA doesn't say your website won't go down. It states how much downtime the provider considers acceptable and what compensation it offers if that limit is exceeded. Anyone buying hosting under the impression that an SLA is an insurance policy against losses will be disappointed after the first serious outage.

How Much Downtime Each 'Nine' Allows

The most honest way to compare one hosting SLA with another is to convert the percentage into minutes. The calculation below uses a 30-day month (43,200 minutes) and a 365-day year:

Promised Uptime	Permitted Downtime per Month	Permitted Downtime per Year
99%	7 hrs 12 mins	3 days and 15 hrs 36 mins
99.5%	3 hrs 36 mins	1 day and 19 hrs 48 mins
99.9%	43 mins 12 s	8 hrs 45 mins 36 s
99.95%	21 mins 36 s	4 hrs 22 mins 48 s
99.99%	4 mins 19 s	52 mins 34 s

Notice the leap. Moving from 99.5% to 99.9% cuts the tolerated downtime from over three and a half hours to less than 45 minutes per month. From 99.9% to 99.99%, the difference is from 43 minutes to 4, and that last 'nine' is the most expensive of all, as it demands true redundancy.

A Practical Example with Moodle

Consider a Moodle VLE with an online exam scheduled for 7 PM. A 99.5% contract allows the environment to be down for three and a half hours that month without any breach. If those three hours fall exactly within the exam window, the provider has met the SLA, and the institution will have to reschedule the assessment, handle student complaints, and explain the problem to the coordination team. In the Moodle environments we manage, this is why we first look at when downtime might occur, not just how much.

How to Read a Hosting SLA: The Clauses That Matter

Before signing any hosting SLA, look for these points in the contract. If any of them are not written in the hosting SLA you received, they don't exist.

1. Metric and Measurement Method. Who measures? The provider itself or an external tool? At what interval? A check every 5 minutes won't detect 3-minute outages.
2. Reporting Period. Monthly is standard. An annual SLA dilutes a major outage over twelve months and almost never triggers compensation.
3. Exclusions. Force majeure, DDoS attacks, third-party failures, customer errors, and scheduled maintenance appear in almost every contract. The problem is when the list is so broad that little is left covered.
4. Definition of Scheduled Maintenance. How much advance notice is given? What is the maximum duration? At what time? Without a written limit, any outage can be reclassified as maintenance.
5. Compensation. Credit on the invoice, discount, or penalty? What is the cap? Is it automatic, or does it need to be requested?
6. Claim Period. Some providers require the customer to open a support ticket within a few days or the following month. Miss the deadline, lose the credit.
7. Response and Resolution Time by Severity. This is the clause that makes the most practical difference, and the one most often missing from off-the-shelf plans.
8. Backup and Restoration. How often is the backup performed (the RPO, or how much data you're willing to lose) and how quickly can the environment be restored (the RTO, or how long you're willing to be down).

Real-World Example of a Compensation Clause

The Locaweb help centre (a Brazilian provider) states a monthly SLA of 99.5% for shared hosting plans, with a scaled discount: 5% when availability is between 99.0% and 99.4%, 10% between 95.0% and 98.9%, 20% between 90.0% and 94.9%, and 30% below 89.9%. And the customer needs to request the calculation via a support ticket at the beginning of the following month. This is a transparent and common model in the market, clearly showing the logic: compensation is proportional to the monthly fee, not to the damage incurred.

Service Credit: Why Your SLA Won't Cover Your Losses

See how the hosting SLA works at the world's largest cloud provider. The Amazon EC2 SLA has two levels:

• Per instance: 99.5% monthly uptime. Below this and up to 99.0%, the credit is 10%. Between 99.0% and 95.0%, 30%. Below 95%, 100%.
• Per region: 99.99%, but only for those distributing instances across two or more Availability Zones within the same region.

In other words: a single machine on AWS, by itself, promises 99.5%, the same range as shared hosting. The 99.99% only exists when you pay for redundancy. And what you receive is credit against that instance's bill.

Now compare that with the cost of being down. The Uptime Institute's 2025 annual outage analysis report indicates that 54% of respondents said their last significant outage cost more than £100,000, and 20% reported costs exceeding £1 million. While the average UK business might not operate on this scale, the proportion holds true: if the server costs £300 per month, the maximum 10% credit is £30. An afternoon of e-commerce downtime, a day of enrolment downtime, or unanswered WhatsApp customer service costs far more than that.

Practical conclusion: the credit provided in the hosting SLA is an incentive for the provider, not an insurance policy for you. What protects your business is the architecture (redundancy, tested backups, monitoring) and the team that responds when something goes wrong. This is precisely the layer that managed hosting with a contractual SLA covers, and a standalone VPS does not.

Maintenance Window: When to Schedule and When Not To

In a hosting SLA, the maintenance window is the agreed period during which the provider can update the operating system, PHP, database, kernel, or hardware, with a risk of unavailability. It's necessary: an unpatched server is a vulnerable server. The problem is when it's used as an excuse.

When to Schedule

• During your audience's lowest actual traffic hours, not just when it's convenient for the provider. For most UK websites, this is Sunday night into Monday morning, but a night-time postgraduate VLE or an e-commerce selling to Portugal will have a different pattern. Check your access graphs before choosing.
• With a staging environment beforehand. Testing PHP or database updates in a copy of the environment reduces the window time from hours to minutes.
• With advance notice. In environments we manage, the rule is to give advance notice, state the estimated duration, and provide a rollback plan.
• With a critical security patch. When a severe and exploited CVE is released, the window might need to be brought forward. Here, speed is more valuable than the perfect timing.

When NOT to Schedule

• Exam or enrolment week for educational institutions. In Moodle, we freeze non-urgent updates during these periods.
• Black Friday, product launches, and active paid campaigns. Tinkering with infrastructure when paid traffic is arriving is burning budget.
• Month-end closing for ERP, financial systems, and invoice issuance.
• Friday afternoon. If the update goes wrong, the team needs to be rested and available to revert it, not starting their weekend.

Moodle Helps: Maintenance Mode

In Moodle, activate maintenance mode before updating. It displays a message to students and maintains administrator access. It seems obvious, but we've received environments from other providers where updates were performed with the VLE open, with a student in the middle of a quiz. If the change involves switching servers, greater care is needed; I detailed the process in how to migrate Moodle to a new server without losing data.

Compound SLA: The Chain Is Only as Strong as Its Weakest Link

Your system rarely depends on just one service. A typical website involves DNS, CDN, web server, database, transactional email service, and increasingly, third-party APIs. When these components are in series (if one fails, everything fails), their availabilities multiply:

• 99.9% × 99.9% × 99.9% = 99.7%, or approximately 2 hours and 10 minutes of tolerated downtime per month.
• With five components each at 99.9%, the result drops to approximately 99.5%.

In practice, this means that the server hosting SLA is not the SLA for your business. An example we've experienced with integrations to the official WhatsApp API: the server can be 100% online, and yet customer service stops because Meta experienced instability, the token expired, or the webhook became unresponsive. A good infrastructure design addresses these points with queues, automatic retries, and alerts, so that an external failure doesn't bring everything else down.

How to Increase Availability Without Multiplying Costs

• Add redundancy only where it hurts. A database with replication and failover usually provides the greatest gain for money invested.
• Use a CDN in front. A CDN serves cached pages even during a short origin outage. The Cloudflare Business SLA, for example, promises 100% uptime for Business plan customers.
• Monitor externally. Measurement must come from a point external to your server; otherwise, when it goes down, the monitor goes down with it.

Common Pitfalls in Hosting SLAs

These are the most common pitfalls I encounter when reviewing hosting SLAs for clients switching from another provider:

• "Network uptime" sold as website uptime. The link was up; your WordPress wasn't. Read what is being measured.
• Maintenance without a cap. Contracts that exclude scheduled maintenance without limiting duration or requiring notice. In practice, any outage can be reclassified.
• Compensation requiring a support ticket with a short deadline. You only discover you were entitled to it after the deadline has passed.
• Support without resolution time. "Response in 15 minutes" that means a robot acknowledging receipt of the ticket.
• Backup without restoration testing. The backup exists, but no one has ever restored it. When needed, the file is corrupted or incomplete.
• SLA that doesn't cover your code. An outdated plugin, a slow database query, or a deployment error can bring down the site, and none of this is the responsibility of a pure infrastructure provider.
• Long-term commitment with a weak SLA. If the service doesn't deliver, you can't leave without a penalty.

Most of these pitfalls disappear when it's clear who is responsible for what. I made a direct comparison in managed hosting vs VPS: who looks after what when your site goes down. And, since an outage due to an intrusion is still an outage, it's worth reviewing the Linux server hardening checklist.

The Cost of Adding a 'Nine' (and When It's Not Worth It)

Each additional 'nine' in the hosting SLA costs more than the previous one. The approximate guideline we use when discussing with clients:

Target	Typical Requirements	Who It Makes Sense For
99.5%	Single server, daily backup, basic monitoring	Brochure website, blog, landing page
99.9%	Well-sized server, CDN, 24/7 monitoring, on-call team, patches within a window	Small e-commerce, Moodle VLE, internal systems
99.95%	Database with replication and failover, zero-downtime deployment	SaaS, ERP, operations selling or serving customers all day
99.99%	Multiple zones, load balancing, tested automatic failover	Operations where minutes of downtime are very costly

When It's NOT Worth Paying for an Extra 'Nine'

• When traffic is commercial and the audience doesn't use the system overnight. An outage at 4 AM on a Sunday might not be noticed by anyone.
• When the bottleneck is the application. If your system crashes due to code or a plugin, server redundancy only duplicates the problem.
• When the cost of downtime is less than the cost of redundancy. Do the maths: how much do you lose per hour of downtime? Multiply that by the extra hours tolerated at the current level. If it's less than the difference in the monthly fee, the extra 'nine' is a luxury.

Before paying for 99.99% in your server's hosting SLA, it's almost always more valuable to ensure a short response time and tested backups. In most outages we handle, what defines the damage isn't the contractual percentage, but how many minutes the team takes to notice and act.

How Agathas Web Addresses This

We have operated Linux servers, Moodle VLEs, and bespoke systems since 2008. Our managed hosting comes with a hosting SLA that answers the questions in this guide in writing, within the contract:

• 99.9% monthly uptime (up to approximately 43 minutes per month), measured by 24/7 external monitoring.
• Response to critical incidents within 15 minutes and resolution within 2 hours, with a runbook for each incident type.
• Daily plus incremental backup, encrypted and off-server, with restoration tested monthly and restoration of the last 24 hours within 4 hours.
• Critical patches within 72 hours of a public CVE, always passing through staging and within a maintenance window agreed with you, respecting exam weeks, campaigns, and month-end closing.
• Contractual penalty if we fail to meet the SLA, and a monthly report with uptime, incidents, and tested backups.
• No tie-in period: monthly contract with 30 days' notice.

In practice, support is provided by the team that operates the environment, with a direct WhatsApp channel. To get started, you request a free diagnosis of your current infrastructure: we analyse your current contract and architecture, point out risks, and if it makes sense, we migrate you within 7 business days, with staging, a low-traffic window, and a rollback plan. If your case is a VLE, the Moodle hosting page has specific details.

Conclusion: Ask in Minutes, Not Percentages

A hosting SLA is only useful when you translate it into minutes, clauses, and responsibilities. Convert the percentage into downtime, find out what is being measured, see how scheduled maintenance is handled, and most importantly, how long the team takes to respond and restore. Credit on the invoice is the least of the benefits; what protects your business is well-designed architecture and people awake when the alert sounds.

If you want a contract where these numbers are written, with a penalty if they are not met, explore Agathas Web's managed hosting and request a free diagnosis of your environment.