Hosting SLA: Uptime and Maintenance Windows Explained

The hosting SLA (Service Level Agreement) is the part of your contract that specifies how long your website or system can be offline before the provider owes you anything. 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, SLA, and maintenance windows in plain English, with real numbers and the fine print that often catches customers off guard.

TL;DR

• 99.9% uptime allows for approximately 43 minutes of downtime per month. 99.5% allows 3 hours and 36 minutes. The difference a "nine" makes is huge.
• A hosting SLA rarely covers your losses: it returns a percentage of your monthly fee as credit. On AWS, an EC2 instance that falls below 99.5% yields 10% credit.
• Scheduled maintenance is usually excluded from uptime calculations. Read how your contract defines the window and how far in advance it's announced.
• A system depends on multiple services. Three 99.9% components in series deliver approximately 99.7% overall.
• What matters most, beyond the percentage: response time, resolution time, and backup restoration time, as written in the contract.

What a Hosting SLA Is (and Isn't)

SLA stands for Service Level Agreement. In a hosting SLA, the contract formalizes 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 daily operations of server management, 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 goal. 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 stricter sense, is the percentage of time it was usable for the user. A server might be powered on, with 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 site was down.

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

An SLA Is Not 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 site won't go down. It states how much downtime the provider considers acceptable and what compensation it offers if that limit is exceeded. Anyone who buys hosting expecting the SLA to be 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	Allowed Downtime per Month	Allowed Downtime per Year
99%	7 hours 12 minutes	3 days 15 hours 36 minutes
99.5%	3 hours 36 minutes	1 day 19 hours 48 minutes
99.9%	43 minutes 12 seconds	8 hours 45 minutes 36 seconds
99.95%	21 minutes 36 seconds	4 hours 22 minutes 48 seconds
99.99%	4 minutes 19 seconds	52 minutes 34 seconds

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 requires true redundancy.

A Practical Example with Moodle

Consider a Moodle LMS 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 violation. If those 3 hours fall exactly during the exam window, the provider has met the SLA, and the institution will have to reschedule the exam, address student complaints, and explain the issue to the administration. 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 themselves 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 rarely 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 actually covered.
4. Definition of Scheduled Maintenance. How far in advance is it announced? What's the maximum duration? At what time? Without a written limit, any outage could be reclassified as maintenance.
5. Compensation. Credit on the invoice, discount, or penalty? What's the cap? Is it automatic or does it need to be requested?
6. Claim Period. Some providers require the customer to open a 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 backups are made (the RPO, or how much data you're willing to lose) and how quickly the environment can be restored (the RTO, or how long you're willing to be down).

Real-World Compensation Clause Example

Locaweb, a Brazilian hosting provider, states in its help center that it offers a monthly SLA of 99.5% for shared hosting plans, with a tiered 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 must request an assessment via a support ticket at the beginning of the following month. This is a transparent and common model in the market, clearly demonstrating 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 that 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 who distribute instances across two or more availability zones within the same region.

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

Now compare that to the cost of downtime. The Uptime Institute's 2025 annual outage analysis report indicates that 54% of respondents reported their last significant outage cost over $100,000, and 20% reported costs exceeding $1 million. While the average Brazilian company might not operate on this scale, the proportion holds true: if a server costs, for example, $60 per month, a maximum 10% credit is just $6. An afternoon of e-commerce downtime, a day of enrollment offline, or unanswered WhatsApp customer service requests cost far more than that.

Practical Conclusion: The credit provided in a hosting SLA is an incentive for the provider, not an insurance policy for you. What truly 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-upon period during which the provider can update operating systems, PHP, databases, kernels, 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 at a time convenient for the provider. For most US-based websites, this is typically late Saturday night or early Sunday morning. However, a night graduate school LMS or an e-commerce site selling to Europe will have a different traffic pattern. Check your analytics before choosing.
• With prior staging. PHP or database updates tested in a staging environment reduce the maintenance window from hours to minutes.
• With advance notice. In environments we manage, the rule is to provide advance notice, state the estimated duration, and outline the rollback plan.
• For critical security patches. When a severe and actively exploited CVE is released, the window may need to be brought forward. Here, speed outweighs the perfect timing.

When NOT to Schedule

• Exam or enrollment weeks in educational institutions. For Moodle, we freeze non-urgent updates during these periods.
• Black Friday, product launches, and active paid campaigns. Tinkering with infrastructure when purchased traffic is arriving is burning through your budget.
• Month-end closing for ERP, financial systems, and invoicing.
• Friday afternoon. If an update goes wrong, the team needs to be rested and available to roll back, 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 LMS open, students in the middle of quizzes. If the change involves migrating to a new server, greater care is needed; I detailed the process in how to migrate Moodle to a new server without losing data.

Composite 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), availabilities multiply:

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

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

How to Increase Availability Without Multiplying Costs

• Add redundancy only where it hurts most. Database replication and failover typically offer the highest return on investment.
• Use a CDN. A CDN can serve cached pages even during a brief origin server outage. Cloudflare's Business SLA, for example, promises 100% uptime for Business plan customers.
• Monitor externally. Measurement must come from a point external to your server; otherwise, if it goes down, your monitor goes down with it.

Common Pitfalls in Hosting SLAs

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

• "Network uptime" sold as website uptime. The network link was up; your WordPress site was not. Read what is measured.
• Unlimited maintenance. A contract that excludes scheduled maintenance without limiting duration or requiring notice. In practice, any outage can be reclassified.
• Compensation requiring a short-notice ticket. You only find out you were entitled to it after the deadline has passed.
• Support without resolution time. "15-minute response" that means a bot acknowledging receipt of your ticket.
• Untested backups. 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. Outdated plugins, slow database queries, or deployment errors can bring down your site, and none of that is the responsibility of a pure infrastructure provider.
• Long-term contracts with weak SLAs. If the service underperforms, you can't leave without penalty.

Many of these pitfalls disappear when it's clear who is responsible for what. I made a direct comparison in managed hosting vs. VPS: who handles 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 a hosting SLA costs more than the previous one. The approximate guideline we use when discussing with clients:

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

When Paying for an Extra "Nine" Isn't Worth It

• When traffic is business-oriented and your audience doesn't use the system overnight. An outage at 4 AM on a Sunday won't affect 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 math: how much do you lose per hour of downtime? Multiply that by the extra hours tolerated at your current level. If it's less than the difference in monthly fees, 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 contract's percentage, but rather how many minutes the team takes to notice and act.

How Agathas Web Addresses This

We have operated Linux servers, Moodle environments, and custom 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 external 24/7 monitoring.
• Critical incident response 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 patch within 72 hours after public CVE disclosure, always passing through staging and within a maintenance window agreed upon with you, respecting exam weeks, campaigns, and month-end closings.
• Contractual penalty if we fail to meet the SLA, and a monthly report with uptime, incidents, and tested backups.
• No long-term commitment: monthly contract with 30 days' notice.

In practice, support is provided by the team operating the environment, with a direct channel via WhatsApp. To get started, request a free diagnostic of your current infrastructure: we analyze your current contract and architecture, identify risks, and if it makes sense, we migrate you within 7 business days, with staging, low-traffic windows, and a rollback plan. If your case involves an LMS, our 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 percentages into downtime, find out what's being measured, see how scheduled maintenance is handled, and most importantly, how long the team takes to respond and restore. Credit on your bill is the least of the benefits; what truly protects your business is a well-designed architecture and a responsive team when an alert sounds.

If you want a contract where these numbers are written, with penalties if not met, learn about Agathas Web's managed hosting and request a free diagnostic of your environment.