Service Level Agreement (SLA) Matrix Markdown Table Template
An SLA matrix is the part of a service agreement that people actually read during an incident. When production is down at 2 a.m., the customer’s on-call engineer wants to know how fast a human will answer, and their account manager later wants to know whether the outage breached the contract and earned a service credit. Support leads use the same table to set paging rules, staffing, and escalation timers.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
Two different promises tend to get blended in these tables, and keeping them apart is the most important thing you can do. Severity response targets describe how your support organisation reacts to a ticket: time to first human response and target time to resolve or mitigate. Availability is a measured property of the service over a period, usually a calendar month, expressed as a percentage of uptime. A Sev-3 ticket does not have its own uptime level; the service has one uptime commitment, perhaps varying by plan.
A good SLA table defines each severity by observable impact so customers and support agents classify incidents the same way, states the coverage hours behind every clock, and is consistent with the arithmetic. If you promise 99.99% monthly availability, your downtime budget is about 4.4 minutes per month, so a four-hour Sev-1 resolution target describes an incident that has already breached the commitment many times over. Readers in procurement will notice.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| Severity Level | left :--- | A label plus a short name (Sev-1 (Critical)), in bold, ordered from highest impact down. Use the same labels your ticketing system and status page use, so customers can select the matching severity when they open a case. |
| Impact Definition | left :--- | Observable criteria, not adjectives: who is affected, which functions fail, and whether a workaround exists. “All users unable to log in” classifies cleanly; “serious problem” does not. Left-aligned because this is prose; separate multiple criteria with <br> (see line breaks). |
| First Response SLA | center :---: | Time from ticket creation to a human response, not an auto-reply. Use < or ≤ consistently and state the unit. Centered. Add the coverage window if it differs per row (“< 4 business hours”). |
| Target Resolution | center :---: | Time to restore service or provide a workaround, which is usually what the vendor can commit to; a permanent root-cause fix may take longer. Say “target” rather than “guaranteed” unless credits apply. Centered so durations line up for comparison. |
| Support Coverage | right ---: | The hours each clock actually runs: 24/7/365 for severities that page an on-call engineer, Business hours (Mon–Fri) for the rest, with the time zone stated. Keep uptime percentages out of this column — availability is measured for the service, not per ticket — and publish them in a separate table keyed by plan. |
How to Fill It In
- 1Start from what you can staff. Check the on-call rota and support hours with the support lead before writing any response time; a
< 15 minutesSev-1 response needs someone paged and awake around the clock. - 2Define each severity with two or three concrete examples from past incidents in your tracker, then test the definitions by having two people independently classify last month’s tickets.
- 3Compute the downtime budget for any availability figure using a 730-hour month: 99.9% allows about 43.8 minutes, 99.95% about 21.9 minutes, 99.99% about 4.38 minutes. Check your incident history to see whether you would have met it.
- 4Write down how availability is measured (external probes, which endpoints, what interval), what is excluded (announced maintenance, customer-caused outages), and the credit schedule for misses.
- 5Have legal review the wording, and keep the Markdown table in sync with the signed agreement — when they differ, the contract wins and the docs mislead.
Ready-to-Paste Variations
Availability commitment with downtime budget and credits
Separates uptime from support response. Downtime figures use a 730-hour month; credit percentages here are examples only, so substitute your own contract terms.
| Plan | Monthly uptime | Allowed downtime / month | Service credit if missed |
| :--- | ---: | ---: | :--- |
| Standard | 99.5% | ≈ 3 h 39 min | None |
| Business | 99.9% | ≈ 43.8 min | 10% of monthly fee |
| Enterprise | 99.95% | ≈ 21.9 min | 10%, rising to 25% below 99.0% |Severity response matrix with coverage hours
A support-only version that adds an update cadence and spells out the exact coverage hours behind each clock.
| Severity | First response | Update cadence | Coverage |
| :--- | :---: | :---: | :---: |
| Sev-1 (Critical) | < 15 min | Every 30 min | 24/7/365 |
| Sev-2 (High) | < 1 h | Every 2 h | 24/7/365 |
| Sev-3 (Medium) | < 4 business h | Daily | Mon–Fri 09:00–17:00 |
| Sev-4 (Low) | < 2 business days | On change | Mon–Fri 09:00–17:00 |Common Mistakes
Attaching a different uptime percentage to each severity level.
Uptime is measured for the service over a month, not per ticket. Put it in a separate availability table keyed by plan, and keep the severity table for response and resolution clocks.
Promising an uptime level your resolution targets contradict.
Do the downtime math. If 99.99% allows about 4.4 minutes a month, a single four-hour Sev-1 breaches it. Either lower the availability figure or shorten the targets with the staffing to back them.
Not saying when the clock runs.
State coverage hours and time zone for every row, and whether business-hours clocks pause overnight and at weekends. “4 hours” means very different things on a Friday evening.
Counting an automated acknowledgement as the first response.
Define first response as a reply from a qualified person who has read the ticket. Customers notice the difference, and so do auditors.
Related Markdown Table Templates
Browse all 50 templatesTeam Roles & Permissions Matrix (RBAC)
Role-Based Access Control matrix mapping organizational roles to CRUD operations, billing controls, and administration privileges.
ROI & Annual Cost Savings Matrix
Financial cost-benefit analysis comparing current vendor costs, manual engineering overhead, and projected tool savings.
Supported Payment Methods & Settlement
Comparison of accepted payment methods, supported currencies, transaction fees, processing settlement times, and geographic coverage.
Service Level Agreement (SLA) Matrix: Frequently Asked Questions
How much downtime does 99.9% uptime allow?
About 43.8 minutes per 730-hour month, or roughly 8.76 hours per year. 99.95% allows about 21.9 minutes a month, and 99.99% about 4.38 minutes. Use the month length defined in your contract when calculating credits.
What is the difference between an SLA, an SLO, and an SLI?
An SLI is the measurement, such as the share of successful requests. An SLO is an internal target for that measurement. An SLA is the external contract, usually with financial consequences, and is normally set looser than the SLO to leave a safety margin.
Should resolution times be guaranteed?
Most vendors guarantee response times and treat resolution as a target, because root causes can sit outside their control. If you do commit to resolution, define it as service restored or a workaround in place, not a permanent fix.
Does scheduled maintenance count as downtime?
Only if your agreement says so. Most SLAs exclude maintenance announced in advance within a stated window. Write the notice period and window into the agreement and add a footnote under the table pointing to it.