Your SLA is a design document
Response times and availability targets are architectural constraints, not commercial terms. Agreeing them without engineering in the room commits you to a system nobody designed.
Most support agreements are negotiated as commercial documents — response times, escalation tiers, credits for breach — and handed to the engineering team after signature. This is backwards. An SLA is a set of constraints on how a system must be built, and agreeing one without engineering input commits you to architecture you have not designed.
The numbers imply an architecture
Consider two commitments that look similar on a contract page:
- Four-hour response, next-business-day resolution, business hours.
- Fifteen-minute response, four-hour resolution, twenty-four hours a day.
The first is a staffing arrangement. The second is an architecture. To meet it you need health checks that detect failure without a human noticing, alerting that reaches someone awake, deployment that can be rolled back quickly and safely, observability good enough to locate a fault in minutes rather than hours, and enough redundancy that a single instance failing is not an incident at all.
None of that is support work. It is design work, and if it was not in the build, no amount of contractual language will produce it. The commitment does not create the capability; it only creates the liability.
Availability is a budget, not a target
"99.9% uptime" is widely quoted and rarely interrogated. It is worth converting into the currency that matters:
| Availability | Downtime per month | Downtime per year |
|---|---|---|
| 99% | ~7 hours 18 min | ~3 days 15 hours |
| 99.5% | ~3 hours 39 min | ~1 day 20 hours |
| 99.9% | ~43 minutes | ~8 hours 46 min |
| 99.95% | ~22 minutes | ~4 hours 23 min |
| 99.99% | ~4 minutes 23 sec | ~52 minutes |
Two things fall out of this table.
Planned maintenance has to be in the number. If your deployment process requires a ten-minute window and you deploy fortnightly, you have spent roughly twenty minutes a month before anything goes wrong — half of a 99.9% budget on routine work. Either the budget accommodates it, or deployment has to become zero-downtime, which is a design decision with real cost.
Above 99.9%, human response stops being viable. A four-minute monthly budget cannot include somebody waking up, reading an alert and connecting to a server. Systems at that level recover automatically or they miss. Committing to 99.99% with a manual runbook is committing to failure with extra steps.
Measure what the user experiences
An availability figure means nothing without a definition of what is being measured. The common failure is measuring the wrong thing: a health-check endpoint returning 200 while the application is unusable because a dependency is down and every real request errors.
Three questions settle it:
- What is the probe? A trivial endpoint, or a synthetic transaction exercising the path a user actually cares about?
- What counts as down? Errors only, or latency past a threshold? A system answering every request in forty seconds is technically available and practically broken.
- Whose fault counts? If a payment provider is down, are you in breach? Both answers are defensible; only one is in the contract, and it should be the one both parties have actually thought about.
Get these wrong and the SLA measures your monitoring rather than your service.
Severity definitions are the load-bearing clause
Response times attach to severities, so severity definitions decide what the agreement actually costs. If "Severity 1" means "any user is affected", every issue is a Severity 1 and the fifteen-minute clock runs permanently. If it means "complete loss of service for all users", almost nothing qualifies and the commitment is decorative.
Useful definitions are written in terms of business impact and are testable without argument at two in the morning. Cannot take payment. Cannot enrol a student. Cannot dispatch an order. These are unambiguous, they map to something the business cares about, and they do not require a judgement call about how many users constitutes "widespread".
The corollary is that severity is not a measure of engineering interest. A subtle data-integrity bug may be far more serious than an outage while being, correctly, a lower severity — because severity governs response time, and the right response to that bug is care rather than speed.
The support model is a design input
Whether you run business hours or around the clock changes the system, not just the rota:
- Business hours tolerates manual recovery and runbooks. Deployment can be scheduled. Observability can be good rather than excellent.
- Extended or follow-the-sun requires handover discipline: an incident opened in one timezone must be intelligible to someone who has not seen it. That means structured incident records and logs someone unfamiliar can navigate.
- Around the clock with tight targets requires the system to defend itself — circuit breakers, graceful degradation, automatic failover — because a human cannot be in the loop within the budget.
Group delivery makes the middle option practical for us in a way it is not for a single-site team: our dedicated engineering teams operate across UK and Egypt hours, which covers a working day well beyond a single timezone without asking anyone to work nights. That is a genuine advantage, and it is also not the same thing as 24/7 — we would rather say so than imply otherwise.
Write the SLA during design
The practical recommendation is simple and rarely followed: draft the SLA while you are designing the system, not when you are signing the contract.
Doing so surfaces the trade-offs while they are still cheap. The business learns that moving from 99.5% to 99.95% means redundancy, zero-downtime deployment and automated failover, with a cost attached. Engineering learns which failures actually matter commercially, which is usually a shorter list than they assume. Both learn whether the dependency chain can support the commitment at all — there is no point promising 99.99% on top of a supplier who offers 99.9%, and that arithmetic is worth doing before signature rather than after.
Error budgets are a better conversation
There is a healthier way to frame all of this, borrowed from site reliability practice: treat the gap between your availability target and 100% as a budget you are permitted to spend.
If the target is 99.9%, the budget is roughly forty-three minutes a month. That is not a failure allowance to be minimised at all costs — it is a resource. Spending it on shipping features quickly is a legitimate use. Spending it on a risky migration that needed doing is a legitimate use. Not spending it at all means the target is too loose, or the team is being more cautious than the business needs.
Framed this way, several arguments resolve themselves:
- Deploy frequency stops being a fight. If the budget is intact, ship. If it is exhausted, stop shipping and stabilise. The rule is mechanical rather than political, which removes the recurring negotiation between delivery pressure and operational caution.
- Reliability work gets prioritised honestly. A team that keeps overspending its budget has a concrete argument for investment, expressed in the same currency the business already agreed to.
- The target itself gets examined. A budget that is never touched invites the question of whether a cheaper target would do — which is a saving nobody looks for when availability is framed purely as a maximum.
This works best when the budget is visible to both engineering and the business, and when exhausting it has an agreed consequence that is written down in advance. Agreed in the abstract, it is a useful discipline. Agreed during an incident, it is an argument.
None of this replaces the SLA. The contract still says what it says. But internally, an error budget turns availability from a target people feel vaguely guilty about into a number that can be spent deliberately — and deliberate spending is the difference between a system that is reliable by design and one that is reliable by anxiety.
Where we sit
We treat support and SLA as part of design rather than a wrapper applied afterwards, and the availability target as an input to cloud infrastructure decisions rather than a claim made about them. In practice that means the conversation about severity definitions and probe design happens in the same weeks as the architecture, with the same people in the room.
It is a less comfortable conversation to have early. It is considerably less uncomfortable than the one where a number in a contract turns out to describe a system nobody built.