An SLA turns vague support promises into measurable commitments. What to put in a software development SLA, the numbers that matter, and how to negotiate them.
A software development SLA is the part of your contract that states how fast a vendor has to respond when your system breaks, and what you get back if they miss. Most development SLAs promise a first response to a critical bug within 15 to 60 minutes and a fix or workaround within 4 to 24 hours, backed by credits of 10% to 30% of the monthly fee when a target slips. Treat these numbers as planning ranges, not legal advice; run final terms past a lawyer.
An SLA has four parts that carry the weight: definitions, targets, remedies, and exclusions.
Definitions come first because every other number hangs off them. What counts as a critical issue? What counts as downtime? If the vendor defines "critical" so narrowly that only a full outage qualifies, a half-broken checkout page can sit unresolved for a week without breaching anything. Read the definitions line by line.
Targets are the response and resolution times per severity level. The table shows the range most firms use. There is no single correct number; a payment platform needs tighter targets than an internal tool.
| Severity | What it means | Typical first response | Typical resolution target |
|---|---|---|---|
| Critical (P1) | System down, no workaround | 15-60 minutes | 4-24 hours, continuous work |
| High (P2) | Major function broken, workaround exists | 1-4 business hours | 1-2 business days |
| Medium (P3) | Minor defect, low impact | 1 business day | 3-5 business days |
| Low (P4) | Cosmetic issue or feature request | 2 business days | Next release or best effort |
Remedies are the credits when a target is missed. A target with no consequence is a suggestion.
Exclusions are the events that don't count against the vendor: scheduled maintenance, force majeure, changes your team makes, third-party outages. They become a problem when written so broadly that almost nothing counts. Agree on a maximum maintenance window and a minimum notice period.
This is the clause vendors lean on to look faster than they are. Response time means an engineer has acknowledged the ticket and started looking. Resolution time means the problem is fixed or a workaround is live.
A vendor can promise a 15-minute response on a critical bug and still take three days to fix it, because response is all they committed to. You want both numbers in writing, with resolution stated per severity level. For a critical issue, a resolution target of 4 hours (with continuous work) up to 24 hours is reasonable depending on the system. If a vendor will only discuss response times and dodges resolution, that tells you how their support actually runs.
Add an escalation trigger. A common one: if a critical issue isn't resolved by half its window, it escalates to a named manager who must provide an update and an ETA.
Uptime matters mainly for software your customers use: a SaaS product, a client portal, a payment flow. For an internal tool only your staff touch, a formal uptime number matters less than a fast response when it breaks.
If you do need an uptime commitment, know what the percentages mean. 99.9% allows about 43 minutes of downtime a month, 99.95% about 22 minutes, and 99.99% about 4 minutes.
| Uptime target | Allowed downtime per month | Allowed downtime per year |
|---|---|---|
| 99.9% | about 43 minutes | about 8.8 hours |
| 99.95% | about 22 minutes | about 4.4 hours |
| 99.99% | about 4 minutes | about 53 minutes |
The credit schedule is where uptime gets teeth. A typical structure credits 10% of the monthly fee for dropping below 99.9%, 20% for dropping below 99.5%, and lets you terminate for cause if availability falls under a floor such as 95%. Check how downtime is measured: is the window monthly, and does it exclude the vendor's own planned maintenance?
Four things get buried in SLAs and cause most of the disputes we see:
Our support model is built around the same split this article describes. Every project ships with defined severity levels, response targets per level, and a maintenance window agreed up front. For clients across the US, Brazil, South Africa, and Singapore, we schedule overlapping hours and a dedicated channel so a critical issue raised during your business day reaches an engineer while it's still your business day. See our dedicated development teams page for the structure.
We've been through enough vendor transitions to know where support usually breaks. We wrote a checklist for taking over a software project that covers the same ground, and a guide on what to check before signing a software development contract that pairs well with this one.
Before you sign, confirm the SLA and the contract don't contradict each other, and that IP and source code ownership live in a separate clause you've already reviewed. An SLA is about speed and uptime, not about who owns the code.
A service level agreement defines the vendor's support obligations: response and resolution times by issue severity, uptime commitments where relevant, and credits or penalties when targets are missed.
Most vendors commit to a first response within 15 to 60 minutes for a critical, system-down issue, and resolution within 4 to 24 hours. Response time is not the same as resolution, so ask for both.
Only if the software is customer-facing or revenue-critical. For internal tools, a fast defect response matters more than a 99.9% uptime number. For a SaaS or payment product, 99.9% monthly uptime with credits below that is a standard starting point.
Credits usually run 10% to 30% of the monthly fee per breach, and are often tiered, for example 10% below 99.9% uptime and 20% below 99.5%. Check the cap and how far in advance you must claim.
Yes. Response time alone lets a vendor acknowledge a ticket in 15 minutes and still take days to fix it. Resolution targets per severity, plus an escalation trigger, are what actually protect you.
Broad definitions of downtime, an uncapped or unannounced maintenance window, and exclusions that shift blame to hosting or DNS providers. Read the definitions and exclusions as carefully as the target numbers.
Planning a custom software project and want the support terms sorted before you commit? Talk to us about your project.
GlobeSoft builds custom software, AI applications, SaaS, FinTech and enterprise systems for clients worldwide. Message us on WhatsApp for the fastest answer, or email us — we typically reply within 24 hours.
Keep reading
A SaaS MVP is not a smaller version of your full product. It is the smallest thing customers will pay for. Here is how to scope it, what to include, and what to skip.
12 min readWhat the discovery phase of a software project covers, what it produces, what it costs, and how to tell a real one from a formality before you commit.
9 min readA guide for non-technical founders who need software built: how to validate the idea, scope an MVP, pick a build path, and hire a team you can actually trust.
12 min readFounders confuse proofs of concept, prototypes, and MVPs, and the confusion costs real money. Here is what each one actually tests and when to build it.
13 min readA practical guide to custom internal tools: what they cost, when building beats buying or low-code, and how to scope one without overbuilding.
11 min readHow to recover a failed software project: the salvage-or-rebuild decision, a clean code handover, what a rescue actually costs, and how to choose the team that takes it over.
