Service Level Agreement Template for Software Support
A service level agreement template sets how fast a vendor responds to issues and what uptime an app gets. Copy it and see an example of response times.
Overview & context
"We'll get back to you as soon as possible" is a response time both sides agree on until something breaks. A service level agreement (SLA) replaces that with specific times. Below is a service level agreement template for app support and operations, a filled-in example of response times and tips for setting an SLA your team can actually meet.
1. What a service level agreement is
An SLA is a written agreement between a vendor and a client about the level of service the vendor provides. It typically covers app uptime, response and resolution times by priority, support hours and what happens if the agreed values aren't met. You need one whenever someone other than the client maintains the app after launch, most often an agency with a support contract.
Two related terms come up with SLAs. According to Google's Site Reliability Engineering book, an SLI (service level indicator) is a measured value, such as the share of successful requests, and an SLO (service level objective) is an internal target for it. The SLA is the commitment to the client including consequences for missing it, which is why it's usually looser than the internal SLO.
2. SLA template for software support
The template covers support and operations for a single app. Fill in the values in angle brackets based on your contract and your team's capacity.
# Sample service level agreement (SLA): <app name>
## 1. Parties and term
- Vendor: <company, contact person>
- Client: <company, contact person>
- Term: from <date> to <date>, renews automatically for <period>
## 2. Scope of service
- Apps and environments: <production, staging>
- Included: bug fixes, library updates and security patches, monitoring, backups
- Not included: new features, end-user support, issues caused by changes on the client's side
## 3. Availability
- Production uptime target: <99.5%> per <calendar month>
- Planned maintenance: announced <3 business days> ahead, window <Tue 8–10 pm>
- Excluded from uptime: planned maintenance, outages of third-party services outside the vendor's control
- Measured by: <uptime monitoring tool>
## 4. Priorities and response times
| Priority | Description | Response | Resolution or workaround |
| --- | --- | --- | --- |
| P1 | <Production is down> | <1 h> | <4 h> |
| P2 | <Key feature broken, no workaround> | <4 h> | <1 business day> |
| P3 | <Bug with a workaround> | <1 business day> | <per release plan> |
| P4 | <Question or minor request> | <2 business days> | <as agreed> |
## 5. Support hours
- Business days <9 am–5 pm>, P1 <24/7>
## 6. Reporting requests
- Help desk: <link>
- Email: <address>
- Phone for P1: <number>
- Response time counts from when the request is created in the help desk
## 7. Backups and recovery
- Backup frequency: <daily>, retention: <30 days>
- Recovery point objective (RPO): <24 h>, recovery time objective (RTO): <8 h>
## 8. Reporting
- Monthly: uptime, requests by priority, response times met, deployed versions
## 9. Missed SLA
- Credit of <5%> of the monthly fee for each P1 resolved late, up to <20%> per month
## 10. Contacts
- Vendor contact: <name, email>
- Client contact: <name, email>3. Service level agreement example: priorities and response times
The most common SLA question is which response times to pick. The table shows a filled-in example for a small business app with support during business hours. The values are illustrative. Shorter response times mean a more expensive service.
| Priority | Example | Response | Resolution or workaround |
|---|---|---|---|
| P1 | The app is down or nobody can sign in | 1 h, 24/7 | 4 h |
| P2 | Invoices can't be issued and there's no other way | 4 h during business hours | 1 business day |
| P3 | Export fails, but data can be downloaded another way | 1 business day | In the next planned release |
| P4 | Question about settings, a text change | 2 business days | As agreed |
4. How to set an SLA you can actually meet
An SLA your team can't meet hurts both sides. These points help you set values that match how support really runs.
5. Where clients should find the SLA and support contacts
A signed SLA usually ends up as a PDF in someone's inbox. When the client needs to report a bug, they look for the support contact and how to report it, not for the contract. That's why the links to the SLA, help desk and contacts belong in the same place the client goes for everything else about the app. The SLA ties into the software maintenance plan, which describes what the vendor does on a regular basis.
In AboutTheApp, you attach a link to the SLA document under Legal & Compliance and links to the help desk and support email under Support. Each client can have their own links for their installation only, marked private and available with that client's unlock code. On their About page, clients also see their environments and deployed versions, so they can name the version they use when reporting a bug.
AboutTheApp holds the links to the SLA and the contacts, but it doesn't measure or evaluate response times or uptime. You need a help desk and an uptime monitoring tool for that.
6. Legal disclaimer
The template and examples in this article are for illustration only. They aren't a legal document or legal advice. Always have your own legal counsel review any service level agreement and adapt it to your terms and the applicable law.
Frequently asked questions
What should a service level agreement include?
Scope of service, the uptime target, priorities with response and resolution times, support hours, how to report requests, backups and recovery, reporting, consequences of missing the SLA and contacts on both sides.
What is the difference between SLA, SLO and SLI?
An SLI is a measured value, like uptime or response latency. An SLO is the internal target for that value. An SLA is the contractual commitment to the client including consequences for missing it, so it's usually looser than the SLO.
What is the difference between response time and resolution time?
Response time says when someone starts working on a request. Resolution time says when the problem is fixed or worked around. An SLA should state both separately.
What are typical SLA response times?
There's no single typical value. It depends on the price and the team's capacity. A common setup has four priorities. For the top one, a production outage, the response comes within hours, including outside business hours.
Where should clients find the SLA and support contacts?
In the same place they find everything else about the app. In AboutTheApp, you attach the SLA link and support contacts to a specific client and they see them on their About page together with their environments and deployed versions.
In short
A good SLA has priorities described with examples, response times the team can handle and it sits next to the app with the support contacts, not in an inbox.
Want the SLA and contacts next to every app?
Add your app to AboutTheApp for free and attach the SLA, help desk and support contacts for each client.