What a Service-Level Agreement Should Actually Cover

Your web host promises 99.9% uptime. Your email provider promises "fast, reliable service." Your developer promises a "quick response time." These are all marketing language. None of them are commitments backed by consequences.

A real Service-Level Agreement—an SLA—is different. It's a contract that says: "We promise X. If we don't deliver X, here's what happens to you—usually a credit or refund."

Most small businesses don't have SLAs with their vendors. They just have terms of service that promise little and commit to nothing. Then when something goes wrong, there's no recourse.

Understanding what a real SLA looks like helps you negotiate better terms with your vendors. And if you provide services to clients, it helps you write SLAs that are honest and defensible.

What an SLA is and what it isn't

An SLA is a contract. It specifies:

• What you're committed to (e.g., 99.9% uptime)
• How it's measured (e.g., monthly measurement, excluding scheduled maintenance)
• What happens if you miss it (e.g., client gets a 10% credit)

What an SLA is NOT:

• Marketing language ("best effort" or "high availability")
• A promise without measurement (uptime guaranteed, but how do you measure it?)
• A promise without consequences (we'll try to be fast, but we'll blame your code if we're not)

The core components of a real SLA

Uptime guarantee: "We guarantee 99.9% uptime measured on a monthly basis, excluding scheduled maintenance windows." This means: of the 730 hours in a month, the service will be up at least 729.27 hours. That's about 43 minutes of allowable downtime per month.

But note the qualifier: "excluding scheduled maintenance." If your host can take down the entire service for 8 hours on Sunday for maintenance, they've excluded it from the uptime calculation. Make sure you understand what's excluded.

Response time: "Critical issues: 15 minutes. High priority: 1 hour. Normal: 4 hours." This specifies how fast your vendor will respond to issues. Response time is not the same as resolution time. It means they'll acknowledge the issue and start working on it.

Resolution time: "Critical issues: 4 hours. High priority: 8 hours. Normal: 24 hours." This is how long they'll take to actually fix the problem.

For an e-commerce site, a 4-hour resolution time might be critical (you're losing sales). For a blog, 24 hours might be fine.

Escalation path: "If the issue isn't resolved in the stated time, it automatically escalates to the manager level." This prevents issues from getting stuck. If your support person forgets about your ticket, it escalates.

Exclusions: "This SLA does not cover: issues caused by customer misconfiguration, denial-of-service attacks, or third-party services." Every SLA has exclusions. Make sure you understand them. If your site goes down because you misconfigured a setting, that's not their fault. If it goes down because someone is attacking your site, that might be excluded. Make sure you understand what is and isn't covered.

Measurement and reporting: "We'll provide uptime reports every month by the 5th of the next month." This means they're publicly tracking it and you can verify it. If an SLA doesn't include measurement and reporting, it's not real—they have no way to prove they met it.

Credits or refunds: "If we miss the SLA, you get a 10% credit on your next month's bill." This is the consequence. It should be meaningful but not so large that the vendor can never meet the SLA. 10% credit for missing uptime is typical.

Common SLA mistakes

The "best effort" SLA: "We'll do our best to keep your site up." This is marketing language. It's unenforceable. Remove it.

The undefine-able SLA: "We guarantee fast response times." What's fast? An hour? A day? If it's not defined numerically, you can't measure whether they met it.

The SLA with no consequences: "We promise 99% uptime." If you miss it, what happens? If nothing happens, it's not an SLA—it's a hope.

The SLA that excludes everything: "This SLA excludes weather, attacks, solar flares, and phases of the moon." If they've excluded enough, the SLA becomes meaningless. Every SLA has reasonable exclusions, but they shouldn't cover normal operating problems.

The SLA nobody reads: "Our SLA is in section 47.3.b of the terms of service." Buried SLAs don't work. They should be clear, separate, and easily referenced.

When you're buying services (hosting, email, support)

Ask your vendor directly: "What's your SLA?" If they don't have one in writing, that's a red flag. At minimum, you should have:

For hosting:

• 99.9% uptime guaranteed
• 15-minute response time for critical issues
• 4-hour resolution time
• Monthly uptime reporting
• 10–20% credit if they miss

For email hosting:

• 99.9% uptime
• No limit on storage or email traffic
• 1-hour response time for outages
• Credit if they miss

For developer/agency support:

• Response time within 24 hours for all issues
• Resolution time within 5 business days for normal issues
• Escalation if not resolved in time
• What happens if they disappear (usually 30-day notice for contract termination)

For most small business needs, these are reasonable. Demanding 99.99% uptime (only 4 minutes of downtime per month) is usually unnecessary and expensive.

Common exclusions you should accept

"This SLA does not cover":

• Scheduled maintenance (if scheduled in advance and you're notified)
• Issues caused by your misconfiguration or misuse
• Denial-of-service attacks (unless they offer DDoS protection)
• Third-party outages (if your site uses a third-party API and that API goes down, it's not their fault)
• Force majeure events (natural disasters, wars, etc.)

Reasonable exclusions protect the vendor from things outside their control. However:

Watch for: Exclusions that are too broad. "Any issue outside our network" is too broad—most issues are partly outside and partly inside. "Any issue involving external services" is too broad—most sites use external services.

Insist on: Detailed exclusions. "Denial-of-service attacks" is okay. "Any security issues" is not—that's too broad and covers cases the vendor should be handling.

When you're providing services (offering a service to clients)

If you're a developer, designer, or agency providing services to clients, you need an SLA in your contract that's honest and defensible.

Example SLA for a custom web development project:

• Response time: 24 hours for all support issues
• Resolution time: 5 business days for normal issues, 48 hours for critical issues
• Uptime: Not applicable during development phase. After launch, 99% uptime excluding scheduled maintenance.
• Support: Includes up to 4 hours per month of included support. Additional support billed at $150/hour.
• Exclusions: Third-party outages, misconfigurations by the client, attacks or security breaches.

What makes this defensible:

• It's specific (not "best effort")
• It's realistic (99% not 99.99%)
• It has clear exclusions
• It specifies what happens after launch vs. during development
• It limits what's included so you don't go bankrupt providing free support

How to handle SLA breaches

If your vendor misses their SLA, they owe you a credit. How to process it:

1. Document the breach. Screenshot the downtime, the support ticket timestamps, whatever proves they missed the SLA.
2. Request the credit in writing. "We experienced downtime on [date] from [time] to [time]. Per your SLA, we're entitled to a 10% credit."
3. Don't accept excuses that aren't in the SLA. "It was because of a recent update" isn't an exclusion in most SLAs. Scheduled maintenance is excluded. This isn't.
4. If they refuse to credit, escalate within the company or move to a different vendor.

Most vendors credit without argument. If they don't, that's a sign they don't take their SLA seriously.

The unrealistic SLA

Be careful about SLAs that are too good. "99.99% uptime guaranteed with 1-hour resolution on all issues for $20/month" is not a realistic SLA. It's a sign the vendor either has no idea what they're promising or they're planning to ignore it.

Realistic SLAs are achievable for the vendor but valuable for you. 99.9% uptime is more realistic than 99.99%. 24-hour response time is more realistic than 1-hour for all issues.

---

FAQ

What's the difference between uptime and response time? Uptime is whether the service is running (your website is accessible). Response time is how fast the vendor will acknowledge and start fixing an issue. They're separate. Your host could have 99.9% uptime but 48-hour response time.

Should we ask for 99.9% or 99.99% uptime? 99.9% is industry standard and realistic for most services (about 43 minutes of downtime per month). 99.99% (about 4 minutes per month) is very expensive to maintain and usually unnecessary. Unless your business can't afford any downtime, 99.9% is plenty.

What if our vendor offers no SLA? That's a risk. It means if something goes wrong, you have no recourse. You can try to negotiate one into your contract. If they refuse, consider switching vendors. For critical services (hosting, email), you should have an SLA.

Can we sue if they miss the SLA? Depending on your contract, probably not for much. SLAs usually cap damages at the credit amount—typically 10–20% of your bill. That's why negotiating realistic terms is important—if the credit is too small, the SLA isn't meaningful.

Should response time and resolution time be the same? No. Response time is how fast they'll start working on it. Resolution time is how long it takes to fully fix it. Response time should be shorter (they should acknowledge quickly). Resolution time can be longer (it might take time to actually fix).

What if a vendor breaks their SLA repeatedly? Start by escalating internally—their management might care even if their support doesn't. If it continues, gather documentation and prepare to move to a different vendor. An SLA that's repeatedly broken is worthless.

Should the SLA include phone support? Only if phone support is critical to your business. For most SaaS and hosting, ticket-based support with defined response times is enough. Phone support is usually more expensive.

What if they credit us but the problem happens again? Keep escalating. A credit is compensation for the breach, not a solution. If they're repeatedly breaching, they don't have adequate infrastructure or staffing. Move to a vendor that can actually deliver.

Should our client-facing SLA match our vendor SLAs? Typically you should offer slightly less to your clients than you get from your vendor. If your host guarantees 99.9%, offer 99% to your clients. This creates a buffer. If your host breaks their SLA, you can often still deliver yours.

How do we prove downtime for credit purposes? Use monitoring services like Uptime Robot, Pingdom, or your host's own uptime monitoring. Get reports showing exactly when the service was down. This is your documentation for requesting a credit.