What belongs in an SLA (and what does not)

Published: March 2026 · Topic: Delivery & support

Service-level agreements are most useful when they describe observable behavior: who responds, how fast, through which channel, and what happens when a severity threshold is crossed. They are a poor place to guarantee business outcomes (“revenue will grow”) or to hide all project risk behind a single uptime percentage.

Start with severities

Define a small number of incident classes (for example: production down, degraded performance, non-urgent defect). Map each to a first-response target and an escalation path. Without severities, every ticket becomes “urgent” and the SLA loses meaning.

Separate uptime from maintenance

Scheduled maintenance, dependency outages outside your vendor’s control, and client-caused misconfiguration are usually excluded or called out explicitly. That is not evasion—it prevents arguments when the root cause is shared.

Pair SLAs with a support scope

Maintenance hours, included releases, and out-of-scope work (new features billed separately) should live in the same packet as the SLA. Procurement teams review them together; hiding scope in email threads helps no one.

We draft support terms alongside delivery contracts so expectations stay aligned after go-live. Contact us if you want a review of your current wording.