What should an SLA actually include?

An SLA, or service-level agreement, is the promise for how a system will be handled after it’s built – how quickly issues get fixed and how often the service is allowed to go down. It’s one of the most important attachments in a hosting agreement, and one of the most misunderstood. Many buyers either buy too little and get caught out at the next breakdown, or buy too much and pay for readiness the system never needs. The key is to set requirements that match your business’s actual needs.

Response time, resolution time, and ticket priority

The first thing to sort out is what these times actually measure, since vendors and buyers often mix up the terms.

• Response time is how quickly the vendor acknowledges the ticket and starts working. It says little about when the issue is actually gone.
• Resolution time is how long it can take until the problem is fixed. That’s the number that protects your business.

A fast response time without a clear resolution time is a trap: you get a friendly “we’re looking into it” and then sit with the system down for two days without the agreement being breached. So always require resolution times, not just response times.

Both should also be tied to priority. A total outage of the core system isn’t the same thing as a crooked icon. A common breakdown is critical (the business is down), high (an important function is down but there’s a workaround), and normal (annoying but not urgent). Define the levels concretely in the agreement – otherwise every ticket turns into a negotiation over how serious it really is.

Reasonable uptime levels and what they cost

Uptime is expressed as a percentage, and the difference between levels looks small but is enormous in both allowed downtime and price. Each extra nine requires more redundancy, more monitoring, and more on-call coverage.

The step from 99.9 to 99.99 percent sounds like a minor detail but often multiplies the cost several times over, since it requires the system to tolerate parts breaking without any disruption. So ask the counter-question before setting requirements: what does an hour of downtime actually cost the business? For an internal tool, the answer is often “annoying but tolerable,” and then 99.9 percent is more than enough. For a payment flow in the middle of the holiday shopping rush, the answer is different.

Match the level to how critical the service is

The most expensive mistake is giving every system the same high level. A well-thought-out maintenance setup splits services apart and sets readiness according to how much they actually matter.

• Business-critical (e.g., an e-commerce checkout): high uptime, short resolution time, round-the-clock on-call coverage.
• Business-important (e.g., an internal ticketing system): good uptime, fixes during business hours, longer margins.
• Supporting (e.g., a reporting tool): basic uptime, longer resolution times, no on-call coverage.

By tiering your services, you pay for high readiness only where it’s needed, instead of putting on-call costs on the reporting tool nobody misses on a Sunday night.

Penalties, measurement, and follow-up that actually happens

Penalty clauses – deductions when levels are missed – are the part everyone wants to negotiate and the one that matters least in kronor. The compensation rarely covers your actual loss from an outage. Their real value is that they force measurement: you can’t claim a penalty without someone measuring the outcome.

And that’s where most SLAs fall apart. A scenario: a company had an agreement with impressive numbers – 99.9 percent uptime, penalties for shortfalls – but no measurement and no monthly report. When the system kept acting up, there was no evidence to point to, and the agreement turned into a paper tiger. An SLA without measurement and reporting is just a statement of intent.

So require three things beyond the levels themselves: how the outcome is measured, a recurring report you actually receive, and a clear consequence for repeated breaches. Then the agreement becomes a management tool instead of decoration.

If you’d like to set service levels that fit your specific systems rather than a standard template, we at Weapp are happy to help – get in touch with a description of what you’re running.