A software SLA (service level agreement) is the part of a support or service contract that states, in measurable terms, what service the supplier will deliver: which systems are covered, how incidents are classified by severity, how fast the supplier responds and resolves, what availability is promised, what is excluded and what happens when targets are missed.
This guide is for founders, operations leads and CTOs who are about to sign, renew or review an SLA for custom-built software, a SaaS product or outsourced maintenance. It is neutral and buyer-side: what each clause should say, how to read the numbers critically and what vendors tend to leave out. For how one provider structures its agreements, see our service-level agreements and support page. For the work an SLA governs, see software maintenance and support.
Key takeaways
- An SLA is only as good as its definitions. Severity levels, the clock and the measurement method matter more than the headline number.
- Response time (someone starts work) and resolution time (service is restored or a safe workaround exists) are different promises. Ask for both.
- A business-hours clock and a 24x7 clock turn the same number into very different waits. Check which one applies.
- Uptime percentages hide large gaps: 99.9% still allows about 43 minutes of downtime in a 30-day month.
- Read the exclusions, the maintenance windows and the remedy clause before the headline numbers.
- Agree backup and restore objectives (RTO and RPO) and the exit and handover terms while both sides are on good terms.
What is a software SLA?
A software SLA is a written agreement that sets the measurable service a supplier commits to for a system: coverage, severity definitions, response and resolution targets, availability, reporting and remedies. It turns "we will support you" into numbers and procedures both sides can check, and it usually sits inside a wider support or services contract.
An SLA does not fix bugs or keep servers running. The work (monitoring, patches, fixes, small improvements) is the maintenance; the SLA is the commitment layer around it. Our guide on what software maintenance covers explains the work itself, including the four maintenance types and a general agreement checklist. This guide goes deeper on the SLA clauses.
What should a software SLA include?
A software SLA should include the covered systems and users, support hours and time zone, reporting channels, severity definitions with examples, response and resolution targets, availability and how it is measured, maintenance windows, exclusions, escalation, reporting, remedies, security incident handling, backup objectives, change handling, and termination and handover terms.
| Clause | What it should state | What to check |
|---|
| Scope | Applications, environments, integrations, user groups | Anything not named is usually outside the SLA |
| Coverage hours and time zone | Days, hours, holidays and the time zone the clock uses | Business hours and 24x7 are different promises |
| Reporting channel | Portal, email, phone or chat that starts the clock | Reports sent elsewhere may not count |
| Severity definitions | Levels by business impact, each with examples | Who classifies, and can you challenge it |
| Response and resolution | Targets per severity, plus update intervals | Both present, with a defined start and stop |
| Availability | Percentage, measurement period and method | What counts as downtime and who measures it |
| Maintenance windows | When, how much notice, whether it counts as downtime | Emergency changes should be covered too |
| Exclusions | Third-party outages, client changes, misuse, new features | Each should be listed, not implied |
| Escalation | Named roles and time-based triggers | Can you escalate from your side |
| Reporting | Frequency and content of service reports | Raw numbers you can verify, not only a summary |
| Remedies | Credits, reviews, termination rights | Caps, claim deadlines and whether credits are the only remedy |
| Security incidents | Notification time, who investigates, who informs regulators | Often missing from support SLAs |
| Backup and restore | RTO, RPO, test frequency | A backup that has never been restored is an assumption |
| Change handling | How requests are estimated, approved and prioritised | Prevents feature requests crowding out fixes |
| Term and exit | Length, renewal, notice, handover duties | Agreed at the start, a clean exit protects your data |
How should severity levels be defined?
Severity levels should be defined by business impact, not by who is shouting, with a plain description and two or three examples from your own operations for each level. Many agreements use four levels, from "service down" to "cosmetic". The definition also says who classifies an incident and how a disagreement is resolved.
Write the examples around your real workflows: "orders cannot be placed" is a better critical example than "major functionality unavailable". Allow re-classification as more is learned, because a problem that looks minor at 10:00 can be critical by noon. Keep your own side honest too: if every ticket is marked critical, the top level stops meaning anything.
What is the difference between response time and resolution time?
Response time is how long it takes the supplier to acknowledge a reported incident and start work. Resolution time is how long it takes to restore normal service or provide a safe workaround. An SLA that sets only response time guarantees a reply, not a fix, so ask for both targets for every severity level.
Two related terms are worth writing in. An update interval says how often you hear about an open incident (for example, every hour for the most severe level). Clock rules say when the clock starts (when the report arrives through the agreed channel), when it pauses (for example, while the supplier waits for information only you can give) and when it stops (service restored and you confirm, or a workaround agreed). Many disputes come from clock rules that were never written down.
What does a sample severity matrix look like?
A severity matrix lists each level with its definition, an example, and the response, update and resolution targets. The figures below are illustrative examples only, written to show the shape of a matrix. They are not Timeline Digital commitments, and real targets depend on how critical the system is and what the supplier can staff.
| Level | Definition | Example | Illustrative response | Illustrative update interval | Illustrative resolution or workaround |
|---|
| Severity 1, critical | System down or core function unusable, no workaround | Customers cannot check out; staff cannot log in | Within 1 hour, on a 24x7 clock | Every 1 to 2 hours | Within 8 hours |
| Severity 2, high | Major function degraded, slow workaround exists | Month-end report fails; one site cannot sync | Within 4 hours, on the coverage clock | Every 4 hours | Within 2 business days |
| Severity 3, medium | Limited fault, reasonable workaround | An export needs manual correction | Within 1 business day | Daily | Within 10 business days or next release |
| Severity 4, low | Cosmetic issue, question or minor request | A label reads wrong | Within 3 business days | On request | Planned into a release |
Treat any table like this as a negotiating checklist, not a benchmark. The point is that every row has a definition, an example and three separate time targets.
Business-hours clock or 24x7 clock?
A business-hours clock counts only the hours the supplier's support desk is open, while a 24x7 clock counts every hour. The same target therefore means very different waits. A four-hour response on a business-hours clock can stretch over a weekend, so confirm the clock, the days, the holidays and the time zone for every target.
Worked arithmetic, using an invented support window of Monday to Friday, 09:00 to 18:00. A Severity 2 incident is reported on Friday at 17:00 with a "4 business hours" response target. One hour remains on Friday, so the remaining three hours run on Monday from 09:00, and the target falls at Monday 12:00. On a 24x7 clock, the same target would fall on Friday at 21:00. Neither is wrong; they are different products, and your system's weekend traffic decides which you need.
How is uptime measured, and what do the percentages mean?
Uptime (availability) is the share of a measurement period during which the service is usable, usually shown as a percentage. The percentages sound close together but allow very different downtime. The table converts each target using the stated assumptions, so you can see what a promise really allows.
Assumptions: a 30-day month is 43,200 minutes and a 365-day year is 525,600 minutes. Allowed downtime is (100 minus the target) percent of that period. Do not multiply the monthly figure by 12, because 12 months of 30 days is 360 days, not 365.
| Availability target | Allowed downtime per 30-day month | Allowed downtime per 365-day year |
|---|
| 99% | 7 h 12 min (432 min) | 3 days 15 h 36 min (87.6 h) |
| 99.5% | 3 h 36 min (216 min) | 1 day 19 h 48 min (43.8 h) |
| 99.9% | 43 min 12 s (43.2 min) | 8 h 45 min 36 s (525.6 min) |
| 99.95% | 21 min 36 s (21.6 min) | 4 h 22 min 48 s (262.8 min) |
| 99.99% | 4 min 19 s (4.32 min) | 52 min 34 s (52.56 min) |
An availability clause is only meaningful if it also says:
- What counts as down. A server answering a ping is not the same as customers being able to place an order. Commonly the definition is tied to a user-facing function or an error-rate threshold.
- Who measures it, from where, and how often. The supplier's own monitor, an independent one, or both.
- The measurement period. Monthly measurement is stricter than annual, because a bad month cannot hide inside a good year.
- What is excluded. Planned maintenance, third-party outages, client-caused problems.
- What happens when it is missed. See the remedies section below.
Be realistic about what you need: a higher target usually means more redundancy, monitoring and on-call cover, so it is a design and budget decision, not only a clause.
Which exclusions and maintenance windows should you read closely?
Exclusions are the situations where the SLA does not apply, commonly third-party service outages, changes made by the client or another vendor, unsupported environments, misuse, force majeure and requests for new features. Maintenance windows are agreed periods for planned work. Both can quietly shrink the promise, so each should be specific and listed.
For maintenance windows, ask how long and how often, at what hours in your time zone, with how much notice, and whether the time counts toward downtime. Unlimited "planned maintenance" at the supplier's discretion can excuse almost any outage. For third-party exclusions, ask whether the supplier must still monitor, work around and communicate the outage.
What are service credits, and what remedies should an SLA offer?
Service credits are a remedy where the supplier reduces future fees when a target is missed, often by a percentage tied to how far the miss was. Credits are one remedy among several. A complete clause also covers escalation, a root-cause review, an improvement plan and, for repeated failure, the right to terminate.
Before accepting a credit clause, check these points:
- Is the credit automatic, or must you claim it within a short deadline?
- Is there a cap, and is it small compared with the business loss an outage causes?
- Are credits your only remedy, or do other rights survive?
- Does a repeated miss give you a right to leave without penalty?
Credits rarely cover real business loss, so the stronger protections are usually the review, the escalation and the exit rights.
How should SLA terms treat security incidents and backups?
An SLA should say how fast the supplier tells you about a suspected security incident, who investigates, what evidence is kept and who informs regulators or customers. It should also state backup frequency, retention and tested restores, expressed as two objectives: how long recovery may take (RTO) and how much data loss is tolerable (RPO).
Both objectives are commonly defined as follows. RTO (recovery time objective) is the maximum acceptable time to bring a system back after an outage. RPO (recovery point objective) is the maximum acceptable amount of data loss measured in time, so it indicates how far back you must be able to recover. In practice, backup frequency drives the RPO and recovery speed drives the RTO. Ask when a restore was last tested, because an untested backup is an assumption. Legal duties for breach notification depend on your jurisdiction and sector; confirm them with your own adviser. Our security and data protection page describes how one provider approaches protection.
How do change requests and exit terms fit in?
An SLA covers keeping the system running, not building new features, so it should say how change requests are raised, estimated and approved, and how they are prioritised against incidents. The exit terms should state the notice period, handover duties, documentation, data export and who holds the code and accounts after the contract ends.
Keep the two separate in practice. Small enhancements can be bundled in a defined allowance or handled as estimated work orders, but they should never silently displace an urgent fix. For exit, ask for current documentation, a credentials inventory, a knowledge-transfer period and confirmation that support quality does not drop during the notice window. Also confirm ownership: code and data should be yours, with source code and documentation transferring on full payment. Our intellectual property ownership page shows how that wording reads in practice.
SLA, SLO, SLI and OLA: what is the difference?
An SLA is the external agreement with consequences. An SLO (service level objective) is a target for a service level, and an SLI (service level indicator) is the measured value, such as the share of successful requests. An OLA (operational level agreement) is an internal agreement between a supplier's own teams that supports the SLA.
The SLI, SLO and SLA wording follows the Google Site Reliability Engineering book, which describes an SLI as a carefully defined quantitative measure of some aspect of the service, an SLO as a target value or range for it, and an SLA as an agreement with the user that includes consequences if the SLO is not met. You do not need to use all four terms, but you do need the SLI to be defined well enough that both sides can compute it.
How does an SLA differ for custom software, SaaS and outsourced maintenance?
The clauses are the same, but the emphasis changes. In SaaS the supplier runs the platform and the SLA is mostly availability and credits. For custom-built software, the SLA covers fixes and support on a system you own. For outsourced maintenance of someone else's code, scope and takeover come first.
| Setting | Who runs the system | Typical SLA focus | Watch for |
|---|
| SaaS product | The vendor, on shared infrastructure | Availability, support response, credits, data export | Standard terms are often take-it-or-leave-it; credits are usually the only remedy |
| Custom-built software | You or a host you control, supported by the builder | Severity and response, resolution, patching, change handling | Hosting and third-party outages sit outside scope unless named |
| Outsourced maintenance of existing code | You, with a vendor taking over | Scope, takeover audit, access, severity, documentation | Undocumented behaviour; the vendor may reasonably exclude parts of a fragile system at first |
What do vendors leave out of SLAs?
The commonly missing items are the clock rules, a resolution target, a definition of downtime, the measurement method, security incident notification, restore testing, claim deadlines for credits, and exit and handover duties. Another frequent gap is a review cadence, so the SLA stays aligned with a system that changes.
The buyer checklist at the end of this guide turns these gaps into questions you can put to a supplier before signing.
Illustrative example
This example is hypothetical; the company and figures are invented. A regional distributor runs a custom order portal and signs a support SLA with a 99.9% availability target measured monthly, a 24x7 clock for Severity 1 and a business-hours clock for the rest. The 30-day allowance is 43.2 minutes.
In one month there are two unplanned outages of 30 and 22 minutes, 52 minutes in total, plus a 2-hour planned maintenance slot that falls inside the agreed window and is excluded. Measured availability is (43,200 minus 52) divided by 43,200, or about 99.88%, which is below the target. The invented credit clause gives 5% of that month's support fee for a miss between 99.0% and 99.9%. The distributor receives the credit, the supplier's root-cause review, and a decision to add monitoring for the failing component. The credit is small; the review is the useful outcome.
When this is the wrong approach
A detailed formal SLA is the wrong tool when the system is a small internal tool with no urgent deadlines, when the supplier is the only person who knows the system and cannot yet be measured, or when the product is still being shaped week to week. A long contract adds overhead without protecting anything.
In those cases, start with a lighter agreement: a named contact, support hours, a response expectation for urgent problems and a review in three months. Avoid chasing a high availability number for a system whose users can tolerate a short outage, and fix a fragile or unsupported system first, because no clause makes an unmaintainable system reliable.
What does a buyer checklist for a software SLA look like?
A buyer checklist for a software SLA confirms that scope, coverage hours, severity definitions, response and resolution targets, availability measurement, exclusions, remedies, security handling, backup objectives and exit terms are all written down. Use it before signing or renewing, and keep a copy with the contract.
- Covered systems, environments, integrations and user groups are named.
- Coverage days, hours, holidays and time zone are stated for each severity level.
- The reporting channel that starts the clock is defined.
- Severity levels have definitions and examples from your business, and a reclassification rule.
- Response, update interval and resolution or workaround targets exist for every level.
- Clock start, pause and stop rules are written down.
- Availability target, measurement period, method and definition of downtime are specified.
- Maintenance windows have limits, notice and treatment in the uptime calculation.
- Exclusions are listed individually.
- Escalation has named roles, time-based triggers and a route you can use.
- Reports are regular and include figures you can verify.
- Remedies cover credits (automatic, capped), reviews and termination rights.
- Security incident notification time and responsibilities are stated.
- Backup frequency, RTO, RPO and restore testing are stated.
- Change request handling and prioritisation are agreed.
- Term, renewal, notice, handover and ownership of code, data and accounts are stated.
Glossary: SLA, a service level agreement with consequences; SLO, a target for a service level; SLI, the measured indicator behind an SLO; OLA, an internal agreement between supplier teams; RTO, the maximum acceptable recovery time; RPO, the maximum acceptable data loss measured in time; service credit, a fee reduction for a missed target; maintenance window, an agreed period for planned work.
How Timeline Digital approaches SLAs
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan, that delivers software as managed projects and supports it under a service level agreement after launch. Each agreement defines severity levels, escalation, reporting and exit terms, with response and resolution targets agreed per contract rather than published as one number. There is no fixed timeframe: the schedule for your system is set from your requirements in the Plan step. The free pilot of 2 to 3 key modules is ready in about 2 days, and with 1,200+ developers we have the capacity to deliver a focused system in as little as 2 weeks. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. Timeline Digital does not publish prices for custom software, because every project is custom. See our service-level agreements and support page, and if you are comparing integration vendors, read about integration SLAs, uptime monitoring and vendor accountability.