What Is an Application Support SLA?

An SLA (service-level agreement) for application support is built from a handful of core terms, and confusing them is where most misunderstandings start. Severity classifies how serious an incident is — commonly something like critical, high, medium and low, each defined with concrete examples specific to the application rather than left abstract. Response time is how quickly the support provider acknowledges and starts working the issue, measured from when it is reported.

Restoration and resolution are often confused with each other, but they are different commitments: restoration means the service is usable again, even through a temporary workaround, while resolution means the underlying cause has actually been fixed. A well-written SLA states targets for each of these separately, because a business waiting for 'the issue to be resolved' needs to know whether that means 'we can process orders again' or 'the root cause is permanently fixed' — those can be hours apart.

Support hours state exactly when the provider is reachable — commonly business hours only, an extended window, or full 24x7 coverage — and this should be stated per severity level, since many contracts offer 24x7 coverage only for the highest severity incidents and standard hours for everything else. Exclusions matter just as much: most SLAs explicitly exclude issues caused by third-party outages (a hosting provider, a payment gateway), a scheduled maintenance window, or misuse outside the application's intended use.

Escalation defines what happens when a target is missed — who gets notified, how quickly, and what happens if the escalated contact also fails to respond. Without a defined escalation path, a missed SLA target typically just sits unresolved until someone on the business side happens to notice and chase it manually.

Imagine a clinic-management software vendor supporting a healthcare provider that uses it for daily patient scheduling. A realistic SLA for that relationship might define a critical incident as 'patients cannot be booked or checked in across the clinic', with a response target of thirty minutes and a restoration target of four hours during clinic operating hours — versus a low-severity issue, like a cosmetic display glitch on an internal report, with a response target measured in business days.

The specific numbers in that example are illustrative, not a standard — every SLA's actual targets should reflect what the business genuinely needs and can afford, since faster targets generally cost more to guarantee. What matters is that severity categories are defined with the business's own real scenarios, not left as generic labels that could mean anything.

An SLA is only useful if performance against it is actually measured and reported, rather than existing only as a promise on paper. Most support arrangements track this through a ticketing system that timestamps when an issue was reported, when it was first responded to, and when it was resolved or restored — from which response-time and resolution-time percentages against target can be calculated.

A periodic review — monthly or quarterly, depending on how critical the software is — is where both sides look at that reporting together, check whether targets are being met, and adjust the agreement if the business's needs have changed since it was signed. An SLA that is set once and never revisited tends to drift out of step with how critical the software has actually become to the business.

Not every application needs the same level of coverage, and paying for 24x7 critical-incident response on a system that only supports an internal, non-urgent process is usually a poor match between cost and actual business need. The right starting question is not 'what SLA can we get' but 'what happens to the business, in real terms, if this specific system is down for an hour, versus a day'.

A system a customer directly interacts with, or one the business could not operate without for even a few hours, justifies faster targets and tighter coverage. An internal reporting tool that is inconvenient but not urgent when it is briefly unavailable can reasonably sit on a lighter, lower-cost tier — matching coverage to criticality, rather than defaulting to the most comprehensive SLA available.