A service level agreement is not a legal annex that gets signed and forgotten. It is the only document that turns the words "we support you" into something that can be measured and held to account. And most of the agreements we see fail on one point: they contain numbers, but they do not define what those numbers mean.

1. Define availability before its percentage

The figure "99.9%" is meaningless until the agreement answers three questions: availability of what, exactly? Measured from where? And over what period?

Server availability is not the same as the availability of the service it delivers. The server may be running while the application does not respond. Measuring from inside the data centre always gives a better result than measuring from where the user sits. And the measurement period changes everything: a percentage calculated monthly allows a longer outage on a single day than one calculated weekly.

To show the practical effect of the difference, this is the cumulative monthly downtime each percentage allows:

Availability Downtime allowed per month (approx.)
99%About 7 hours 12 minutes
99.5%About 3 hours 36 minutes
99.9%About 43 minutes
99.95%About 22 minutes
99.99%About 4 minutes 20 seconds

The difference between 99% and 99.9% looks small on paper, but in practice it is the difference between a lost working day and a lunch break. And the higher the percentage, the higher the cost, so choose what your critical systems actually need, not the highest number on offer.

2. Classify incidents by impact, not by technology

Good classification starts from an incident's impact on the business, not from the type of system that failed. An example of a practical classification:

  • Critical: a complete outage of a service that stops work, or a possible data leak.
  • High: a major performance degradation, or a failure affecting a group of users where a temporary workaround exists.
  • Medium: a fault affecting one user or a limited function without stopping work.
  • Low: requests, scheduled changes and enquiries.

More important than the classification itself: who classifies? If the contract leaves classification to the provider alone, the provider has a permanent incentive to downgrade incidents. Require a way to dispute the classification, and automatic escalation to the higher level if an incident runs past a set time.

3. Separate response time from resolution time

Response time is how long it takes until a qualified person actually starts working on the incident, not until you receive an automated reply. Resolution time is how long it takes until the service is back. Committing to the first alone is common because it is easy, but it protects no one.

The realistic answer: a contractual commitment to response time, a target resolution time for each level, and mandatory escalation when an incident exceeds it. A provider who refuses any commitment on resolution is asking you to pay for the attempt, not for the result.

4. Exclusions: the clause few people read

Every agreement excludes some cases from the availability calculation, and that is legitimate. What is not legitimate is exclusions so broad that they swallow the commitment. Review this clause carefully:

  • Scheduled maintenance: how many hours a month? With how much advance notice? Does it count against availability?
  • Third-party failures (telecoms, the cloud): does the provider's commitment stop entirely, or do they remain bound to follow up and escalate?
  • Changes made by your own team: acceptable as an exclusion, but what counts as a change must be defined
  • Force majeure: precisely defined, not an open-ended phrase

5. Consequences of a breach

An agreement with no consequence for a breach is a statement of intent. A consequence does not necessarily mean large financial compensation; service credits in this field are usually token amounts compared with the actual loss. More important in practice is the right to terminate on repeated breaches, because it is the only tool that keeps the provider serious after the contract is signed.

6. Reporting and review

An agreement that produces no periodic report cannot be verified. Require a monthly report showing measured availability against the committed level, the list of incidents with their levels and times, the status of backups and updates, and what changed in the environment.

And require a periodic review with management, not with the technical team alone. The review is where the numbers become decisions: do we move up a tier? Do we fix a recurring cause? Do we change the scope of the service?

The practical test for any agreement: read it and imagine the worst possible month. If you cannot tell from it exactly what you are entitled to claim in that month, the agreement is incomplete.

The bottom line

A good agreement is short but precise: it defines what it measures, classifies what happens, commits to a time, sets out the exclusions clearly, attaches a consequence to a breach, and produces a report that can be reviewed. Anything beyond that is legal detail that changes nothing on the day the system goes down.