Service Level Agreement Template for Agencies (2026)

A service level agreement template for a software agency defines what "supported" actually means after launch: how much uptime you promise, how fast you respond to each severity of problem, and what the client gets back if you miss. In 2026, most published SLA templates are written for enterprise IT or generic managed services; almost none fit a small agency running support and maintenance on the apps it built. This one does. Below is a copy-paste SLA you can drop into a support retainer, plus the tier tables and exclusions that keep it enforceable without quietly bankrupting you.

What a software agency SLA actually covers

An SLA is not a sales document and it is not your contract. It is the operating schedule that sits underneath the contract and turns "we support the app" into measurable, defensible commitments. It answers four questions a client will eventually ask under pressure:

• Is the app supposed to be up right now, and by whose definition?
• I reported a problem an hour ago; when will someone actually respond?
• Who decides whether this is an emergency or a Tuesday?
• If you miss, what do I get?

The SLA normally lives as an exhibit to your master service agreement and governs the ongoing work your retainer agreement bills for. The MSA sets the legal terms; the SLA sets the numbers.

The five parts every agency SLA needs

Strip away the boilerplate and every workable agency SLA reduces to five moving parts:

1. Covered scope: which apps, environments, and components are in, and which are explicitly out.
2. Availability commitment: the uptime percentage and how it is measured.
3. Severity model: a shared definition of Sev 1 through Sev 4 so nobody argues about whether a bug is "critical".
4. Response and resolution targets: a matrix mapping each severity to a promised first-response time and a target restore time.
5. Remedies: the service credits owed when you miss, and the exclusions that pause the clock.

Get those five right and the rest is formatting.

Uptime tiers: pick a number you can actually hold

The single most common agency mistake is promising "99.9% uptime" on a two-person support rotation. Availability is a budget of allowed downtime, and the tiers get expensive fast. This is the standard nines-of-availability math applied to a monthly window:

For most agencies, 99.5% measured monthly is the honest ceiling on a standard retainer. Promise 99.9% only if you are being paid for monitoring and an on-call rotation, because at 43 minutes a month a single bad deploy can blow the quarter. Price the higher tiers as their own line item; the packaging logic is the same one in the guide on pricing AI builds from hourly to outcome-based.

Severity and response-time matrix

The severity model is where SLAs live or die. Define the levels by business impact, not by how the developer feels about the ticket, and attach two clocks to each: time to first human response, and target time to restore service. Business-hours coverage unless the client pays for 24x7.

Two rules make this hold up. First, "resolution" for Sev 1 means service restored, which can be a workaround; the permanent fix can follow. Second, anything that is really new scope, not a defect, exits the SLA and enters your change-request process so support hours are not silently consumed by feature work.

Service credits: the remedy that keeps the SLA honest

An SLA with no remedy is a wish. Service credits are the standard remedy: if you miss the availability target in a month, the client gets a percentage of that month's support fee back as a credit. Keep it proportionate and capped so a bad month does not become a bad quarter.

Credits should be the sole and exclusive remedy for a miss, capped at 50% of the monthly fee, and claimed by the client within a set window (30 days is standard). Without the cap and the claim window, a single incident can be re-litigated forever.

The AI-app exclusions most templates miss

Agencies shipping AI-native apps in 2026 carry a dependency their SLA templates never mention: the app's behavior depends on third-party model and API providers you do not control. Your exclusions section has to name them, or you are on the hook for OpenAI, Anthropic, or a hosting provider having a bad day. Standard exclusions to carve out of both the uptime clock and the resolution clock:

• Downtime or degradation caused by third-party providers (model APIs, payment processors, email, hosting) outside your reasonable control.
• Client-caused issues: changes the client made, content they uploaded, credentials they leaked, or usage beyond agreed limits.
• Scheduled maintenance announced in advance (define a notice window, for example 48 hours).
• Force majeure, and any period the client's account is past due.
• Anything outside the covered scope, including new feature requests.

Naming the model-provider dependency explicitly is the single most important line an AI-era agency SLA adds over a generic one.

Copy-paste service level agreement template

Drop this into your support retainer, fill the bracketed fields, and adjust the tables above to the tier you sell. Plain text so it pastes anywhere.

SERVICE LEVEL AGREEMENT (SLA)
Exhibit to the Master Services Agreement between [Agency] ("Provider")
and [Client], effective [Date].

1. COVERED SERVICES
   This SLA covers support and maintenance of the following application(s)
   and environment(s): [App name(s), production environment URL(s)].
   Components in scope: [application code, database, hosting configuration].
   Out of scope: new features, third-party services, and anything in
   Section 7 (Exclusions).

2. TERM
   This SLA runs concurrent with the support retainer and renews with it.

3. AVAILABILITY COMMITMENT
   Provider commits to [99.5%] monthly uptime for the production
   environment, measured as (total minutes - unplanned downtime) / total
   minutes, excluding periods listed in Section 7.

4. SUPPORT HOURS AND CHANNELS
   Support is provided [Mon-Fri, 9:00-18:00, Client local time] via
   [email/ticket portal]. After-hours Sev 1 coverage: [included / add-on].

5. SEVERITY LEVELS
   Sev 1 (Critical): app down or unusable for all users, or data-loss risk.
   Sev 2 (High): major function broken, no reasonable workaround.
   Sev 3 (Moderate): minor function impaired, workaround available.
   Sev 4 (Low): cosmetic issue, question, or enhancement request.

6. RESPONSE AND RESOLUTION TARGETS (business hours)
   Sev 1: respond 1h,  restore 8h (workaround acceptable).
   Sev 2: respond 4h,  resolve 2 business days.
   Sev 3: respond 1 business day, resolve 5 business days.
   Sev 4: respond 2 business days, addressed in next scheduled release.

7. EXCLUSIONS (pause both clocks)
   Third-party provider outages (model/AI APIs, payments, email, hosting);
   client-caused issues; announced scheduled maintenance ([48h] notice);
   force majeure; periods the account is past due; out-of-scope requests.

8. SERVICE CREDITS
   If monthly uptime falls below the commitment, Client may claim a credit
   against that month's support fee: 10% (up to 0.5 pt below), 25% (0.5-1.5
   pt below), 50% (more than 1.5 pt below). Credits are the sole and
   exclusive remedy, capped at 50% of the monthly fee, and must be claimed
   within 30 days of the affected month.

9. CLIENT RESPONSIBILITIES
   Provide timely access, a single point of contact, reproducible reports,
   and keep third-party accounts and payment methods current.

10. REPORTING AND REVIEW
   Provider reports monthly uptime and ticket metrics. Parties review the
   SLA every [6 months] and may adjust tiers by written agreement.

Signed: ____________________ (Provider)   ____________________ (Client)

A worked example

An agency runs a $2,400 per month support retainer on a client's AI-powered booking app, committed to 99.5% uptime. In March the app is down for two hours during a model-provider outage and for another 50 minutes after a bad deploy. Total unplanned downtime that counts against the SLA is 50 minutes, because the two-hour third-party outage is excluded under Section 7. Fifty minutes against a ~44,640-minute month is 99.89% uptime, above the 99.5% commitment, so no credit is owed. Without the third-party exclusion, the same month would have read as 99.62% (still above target here, but the exclusion is what makes the number defensible when the outage is longer). That one clause is the difference between an SLA you can stand behind and one that quietly transfers a vendor's reliability risk onto your margin.

How to put the SLA into effect

1. Pick the uptime tier you can genuinely hold on your current rotation, not the one that sounds impressive.
2. Confirm you have monitoring that can actually measure the uptime number you are promising. If you cannot measure it, do not promise it.
3. Map every covered app and environment in Section 1, and list the third-party providers you depend on in Section 7.
4. Attach the SLA as an exhibit to the master service agreement, not as a standalone email.
5. Set a monthly reporting rhythm; a one-line uptime and ticket summary each month is what makes renewals easy.

Borrow the severity language from an established incident severity model if your team does not already share one; consistency across tickets matters more than the exact wording.

If you take one thing from this: an SLA is a downtime budget with a remedy attached. Promise the uptime tier you can measure and hold, name your third-party dependencies as exclusions, and cap the service credit, so a bad month costs you a credit, not the client relationship.