A system in production needs an agreement about what happens when something goes wrong. I have defined SLAs for this, and I learned that the numbers are the smaller part of the work. The larger part is agreeing, with the client, what each number means and how it will be measured.
The familiar part: response and resolution
Incident SLAs are well understood. Someone reports a problem, someone answers, and the target depends on how serious it is. The things I try to settle are how severity is defined, by business impact and not by who shouts loudest, which hours the cover applies to, and when the clock starts and stops.
I also agree how the SLA is reported: a regular report, reviewed in a regular service meeting, so that trends are discussed before they become disputes. A number that nobody looks at does not protect anyone.
The hard part: application performance
Setting SLAs on application performance was hard. Speed is not one number. It depends on load, on data volume, on the network and often on third-party systems, and no single party owns all of them. A user also experiences slowness differently from the way a monitoring tool records it.
The usual failure is a promise written before anyone has measured anything. It looks precise, and it is either impossible to keep or so loose that it protects nobody.
A second difficulty is that performance degrades gradually. An incident is a clear event, but a system that gets a little slower each month never raises an alarm unless a threshold exists, and the threshold is exactly the hard thing to set. So I would rather agree a small set of measures and a review point than try to cover every scenario in the first contract.
How I approach it
- Measure first. Get a baseline from testing or early production use before committing to a limit.
- Choose a few transactions that matter to users, not every screen.
- Define the measure exactly: where it is taken, which average or percentile, over what period and under what load.
- Name what is outside our control, such as third-party systems or the client network, and treat it separately.
- Review after the first months, with real data, and adjust together.
An SLA is a shared expectation
I also agree in advance what happens when a target is missed. The first step is an analysis and an improvement plan, with penalties, if any, as a last resort. A penalty-first approach pushes both sides to argue about the measurement instead of fixing the cause.
I do not see an SLA as a stick to hit the other side with. It tells both parties what to expect, so that a slow day is a conversation about a known number and not a surprise. That is why I prefer a performance target we can both measure and keep over an ambitious one that looks good in the contract and fails in the first month.