A software development SLA should define what’s covered, a short list of measurable targets (availability, response and resolution times by severity, and a few delivery-quality measures), which hours and time zone those targets apply to, how performance is reported, and what happens when targets are missed. If two reasonable people could disagree on whether a target was met, it isn’t written tightly enough.
On this page
- What is a software development SLA?
- Which metrics belong in the SLA?
- What do example SLA targets look like?
- How should an SLA handle time zones and offshore teams?
- How should penalties and service credits work?
- How do you keep an SLA alive after signing?
- Does an SLA suit every engagement?
- Frequently asked questions
Most SLA disputes we see don’t come from bad faith. They come from words like “timely”, “high quality” and “best effort”, from response times that ignore time zones, and from a document nobody looked at after signing. Here’s what to put in, with example targets you can adapt.
What is a software development SLA?
It’s the part of your contract that defines how well and how reliably a provider delivers an ongoing service: the targets, how they’re measured, who reports them, and the remedies when they’re missed. It sits alongside the master services agreement, which covers legal terms, and the statement of work, which covers what gets built.
| Document | Answers | Examples |
|---|---|---|
| MSA (master services agreement) | What are the legal ground rules? | Liability, IP, confidentiality, disputes, termination |
| SOW (statement of work) | What will be delivered? | Features, milestones, acceptance criteria, price |
| SLA (service level agreement) | How well and how reliably? | Availability, response times, quality targets, reporting, credits |
For a pure build project, the SOW does most of the work. The SLA becomes important as soon as the provider supports, maintains or operates something your customers depend on.
Which metrics belong in the SLA?
Keep it to five to eight metrics you can measure automatically: availability of systems the provider operates, response and resolution times by incident severity, and two or three delivery measures such as change failure rate, lead time for changes or escaped defects. More metrics create noise, not control.
- Availability: percentage uptime per month, measured by an agreed monitoring tool, excluding agreed maintenance windows.
- Response time: time from an incident being reported to a named person acknowledging it and starting work.
- Resolution time: time to restore service or deliver a workaround, by severity.
- Change failure rate: share of deployments that cause an incident or need a rollback.
- Lead time for changes: time from code merged to code in production.
- Escaped defects: bugs found in production that should have been caught in testing.
The delivery metrics borrow from DORA’s software delivery metrics, which are widely used and easy to measure from your pipeline. Avoid putting velocity or story points into an SLA. They’re planning tools, and making them targets distorts them.
What do example SLA targets look like?
Here is an illustrative set for a small production SaaS supported by an offshore team. These are examples to adapt, not industry standards. Set targets from your own customer commitments and the provider’s measured baseline, and say clearly whether each clock runs in business hours or around the clock.
| Severity | Definition | Example response | Example resolution or workaround |
|---|---|---|---|
| P1 critical | Service down or data at risk, no workaround | 30 minutes in covered hours | 4 hours |
| P2 high | Major function impaired, workaround exists | 2 hours in covered hours | 1 business day |
| P3 medium | Limited impact | 1 business day | 5 business days |
| P4 low | Cosmetic or minor request | 2 business days | Next planned release |
Add availability (for example 99.5% monthly for production APIs) only for systems the provider actually operates. A vendor can’t promise uptime for infrastructure you run.
How should an SLA handle time zones and offshore teams?
State which time zone and which hours each target uses, define what “covered hours” means, and price any out-of-hours or on-call coverage explicitly. Include both countries’ public holidays. Without this, a “30-minute response” can mean very different things to each side.
For a concrete example: Dignep’s standard hours are 09:00–18:00 Nepal Time (UTC+5:45). That overlaps with most of the working day in India, about 3–4 hours in Sydney, about 4 in Central Europe and about 3 in the UK. US East and West Coasts have no natural overlap, so with US clients we agree a fixed daily call window before kickoff, and any cover outside our hours is scoped and priced separately. Festival leave around Dashain and Tihar in October and November also belongs in the holiday calendar. Our guide to managing time zone differences with offshore teams covers handoffs in more detail.
How should penalties and service credits work?
Service credits should be big enough to matter but small enough that the relationship survives a bad month. Most contracts express them as a percentage of the monthly fee for the affected service, with an overall cap, a short cure period for first breaches, and a right to terminate for repeated failure. Agree a baseline month before credits apply.
- Credits: a percentage of the monthly fee per breached metric, capped in total.
- Cure period: time for the provider to fix a first breach before credits apply.
- Chronic failure: termination rights if the same target is missed for several consecutive periods.
- Exclusions: client-caused outages, third-party failures outside the provider’s control, and agreed maintenance.
Some teams add incentives for sustained over-performance. They can work, but keep them simple. Complicated bonus formulas tend to produce arguments rather than better service.
How do you keep an SLA alive after signing?
Report against it automatically, review it monthly, and recalibrate it every year or after major changes. Name an owner on each side. The point of the monthly review isn’t to collect credits. It’s to spot trends early and decide what to fix.
- Pull metrics from your tools (monitoring, ticketing, CI/CD) rather than from manual spreadsheets.
- Share a short monthly report: targets, actuals, breaches, causes and actions.
- Escalate repeated breaches to a named senior contact on each side.
- Re-baseline after big changes such as a new architecture or a large traffic increase.
Does an SLA suit every engagement?
No. For a short PoC, an early MVP or pure staff augmentation, a heavy SLA adds cost without much benefit. A light statement of response expectations and a weekly demo is enough. SLAs earn their keep once software is in production and customers depend on it.
As engagements mature, they often move from time-and-materials to an SLA-backed arrangement. Dignep is certified to ISO/IEC 20000-1:2018, which requires us to define, measure and review service levels; what ISO 20000-1 means for software SLAs explains what that covers. SLA-backed support usually runs alongside a dedicated team or a software outsourcing engagement. If your SLA also needs to cover security incidents and compliance evidence, see our cybersecurity and GRC services.
Frequently asked questions
How long does it take to agree an SLA?
For a new engagement, usually a few weeks alongside the contract: a workshop to agree priorities, a draft, and legal review. A practical approach is to start with a light SLA, collect a month or two of real data, then tighten the targets.
Does a small startup need a formal SLA?
Once customers rely on the product, yes, but it can be one page: scope, severity definitions, response targets, covered hours, a monthly review and an escalation contact. That covers the most common disputes.
