Application support SLA: what it actually guarantees and what to check
An SLA should turn expectations for application support into specific, measurable commitments. A four-hour response does not mean a four-hour fix, and continuous monitoring does not necessarily include a 24/7 human response. The real value of an SLA depends on its service scope, coverage hours, incident priorities, measurement method, and consequences when a commitment is missed.
An informal promise that “someone will look into it” may be enough while an application is only a minor internal tool. Once it affects orders, production, employee workflows, or customer service, the business needs to know who owns an incident, when investigation will begin, and how escalation works. A useful SLA resolves those questions before the first serious outage.
What is an SLA, and what does it guarantee?
An SLA, or Service Level Agreement, is usually part of an application support contract or one of its schedules. It defines measurable conditions for delivering the service, such as response time, availability, service hours, incident handling, and escalation rules.
An SLA does not automatically guarantee continuous operation or an immediate fix for every defect. It guarantees only what it states clearly. If it promises a response within four hours but does not define a restoration or resolution target, it should not be interpreted as a promise to fix the application within four hours.
Three related terms make the distinction easier:
- A Service Level Indicator (SLI) is a measured value, such as availability, successful request rate, or response latency.
- A Service Level Objective (SLO) is the target for an indicator, such as 99.9% availability over a calendar month.
- A Service Level Agreement (SLA) turns selected objectives into an agreement between customer and supplier and may define consequences when they are missed.
Google Site Reliability Engineering uses the same distinction. The practical lesson for customers is straightforward: every contractual promise needs an indicator, a target value, a measurement period, and a defined process when the target is not met.
Response, restoration, and resolution are different times
The most common misunderstanding in application support is treating three incident milestones as if they were interchangeable:
| Milestone | What it means | What it does not mean |
|---|---|---|
| Response | The supplier takes ownership, assesses impact, and starts handling the incident. | The application has been fixed. |
| Restoration | The service is usable again, perhaps after a rollback or temporary workaround. | The underlying cause has been removed. |
| Resolution | The root cause has been removed or a permanent fix has been deployed. | All three milestones happen at the same time. |
For example, card payments stop working after a new release. Support acknowledges the incident within 30 minutes, rolls back the release during the next hour, and restores payment processing. A permanent correction is deployed on the following business day after analysis and testing. The response time is 30 minutes, restoration takes 90 minutes, and final resolution comes later. Each number describes a different outcome.
A fixed resolution time is not always a reasonable commitment. The failure may involve a payment gateway, cloud platform, or integration outside the support team's control. A practical SLA will often guarantee a fast response, regular progress updates, and an estimate after initial diagnosis. Critical systems may also require a separate restoration target.
24/7 monitoring does not automatically mean 24/7 support
Monitoring can check an application continuously while people respond only during defined service hours. A system may detect an outage at 2 a.m. on Saturday, yet the contractual response clock may start at the next service window. Continuous technical observation and an on-call engineering team are different services.
Before signing, verify:
- the days and hours during which support operates;
- whether response time is counted only within those hours;
- which reporting channel starts the agreed response clock;
- who receives monitoring alerts and what action follows;
- whether critical incidents receive out-of-hours on-call coverage.
If an application generates revenue at night, on weekends, or during public holidays, support coverage must reflect that reality. The statement “monitored 24/7” does not meet that requirement by itself.
Seven criteria for comparing application support SLAs
1. Service scope and responsibilities
The SLA should identify the applications, environments, and components it covers. Does it include production, testing, databases, integrations, domains, DNS, certificates, and infrastructure? Exclusions and responsibility boundaries are equally important. Without them, an incident can fall between several suppliers with nobody required to coordinate the response.
2. Priorities based on impact
A critical incident should be defined by measurable impact, not the urgency of the request. Examples include an application unavailable to every user, an inability to accept orders, or a risk of data loss. A limited defect with a workable alternative may deserve a lower priority. The SLA should also explain who assigns a priority and when it can be changed.
3. Time and service windows
For every priority, the document must state whether its target covers response, restoration, or resolution. It also needs a starting rule. A request submitted outside support hours may start the clock immediately or when support opens; either model can work, but the agreement must choose one.
4. Communication and escalation
Define reporting channels, authorised contacts, required incident details, and the frequency of updates during a critical issue. Useful escalation is more than another phone number. It establishes who can decide to roll back a release, disable part of the service, or involve an infrastructure provider.
5. Availability measurement
Availability should be measured from a perspective that reflects the user's experience. A running server does not prove that a customer can complete an order. The SLA therefore needs to identify the data source, monitored user journeys, sampling interval, and evaluation period. The AWS Well-Architected Framework also notes that planned maintenance and dependencies on other systems affect the calculation.
For a service operating continuously over 30 days, common targets allow approximately the following maximum downtime:
| Availability | Maximum downtime per 30 days |
|---|---|
| 99% | 7 hours 12 minutes |
| 99.9% | 43 minutes 12 seconds |
| 99.99% | 4 minutes 19 seconds |
Each additional “nine” requires more resilient architecture, redundancy, recovery automation, and testing. A higher percentage therefore has a cost and may not be the economically correct choice.
6. Backups, RTO, and RPO
The statement “data is backed up” is not enough. A critical application requires a defined backup frequency, retention period, and evidence that restoration is tested. Recovery Time Objective (RTO) sets the target time for restoring service. Recovery Point Objective (RPO) expresses how much data, measured in time, the business can afford to lose. Both targets should reflect the real cost of lost operating time and information.
7. Exclusions, reporting, and consequences
An SLA should list events excluded from its calculation, such as planned maintenance or an outage in a third-party platform. It should also define the report the customer receives and what happens after a missed commitment. The consequence may be a service credit, but it could also require a root-cause analysis, corrective plan, or change to the operating process.
How basic application support works at 1. Web IT
With basic application support from 1. Web IT, we guarantee a response within four hours for requests sent to podpora@1webit.cz or reported on +420 773 337 303 during service hours from 9:00 a.m. to 5:00 p.m. This is a response commitment, not a guarantee that every request will be permanently resolved within four hours.
Basic support includes continuous availability monitoring, regular security checks, a testing server, operation of a backed-up GitLab repository for up to ten users, Bitwarden password management for the organisation and ten users, and project administration covering related domains, DNS, and servers. The service therefore provides the application's operational foundation rather than merely receiving defect reports.
Application support still needs to be distinguished from server and infrastructure monitoring. Automated monitoring may run continuously, but human response follows the conditions of the selected service. Out-of-hours on-call coverage, severity-based response targets, or further commitments can be defined individually as extended support.
How to choose the right SLA level
Do not begin with “How fast should support be?” Begin with “What happens if the application is unavailable for one hour?” Estimate lost orders, unproductive staff time, contractual exposure, and customer impact. Then identify the genuinely critical functions and decide whether they require a fast response, fast restoration, or both.
A simple impact model helps:
- Low impact: A manual workaround is available and customers are not blocked. Support during business hours and a guaranteed response may be sufficient.
- Medium impact: The outage affects a team or some customers, and losses grow with each hour. Multiple priorities, a shorter critical response time, and regular updates become valuable.
- High impact: The application directly controls sales, production, or sensitive data. The business needs restoration targets, out-of-hours coverage, tested backups, and an architecture capable of meeting those commitments.
Before signing, also check how access, documentation, and source code will be transferred when the relationship ends. Support should not create avoidable dependency on one supplier. Our guide to an application handover when switching vendors explains the practical steps.
A useful SLA is realistic, measurable, and clear
The purpose of an SLA is not to secure the shortest number in a table. It is to set a service level that matches the business impact of downtime and can be delivered technically and economically. The essential checks are to distinguish response from restoration and resolution, understand the actual service hours, and reject any availability percentage that lacks a measurement method.
If you are selecting support for an existing application, we can first assess its technical condition, dependencies, and operational risks. Those findings provide the basis for an application support model that fits your project, rather than a generic SLA that is either unnecessarily expensive or insufficient.
Frequently asked questions about application support SLAs
Does a four-hour response mean a four-hour fix?
No. Response time defines when support must take ownership of a request and start handling it. Restoration or final resolution must be stated separately if either is guaranteed.
Does 24/7 monitoring guarantee an engineer will respond at night?
Only if the agreement says so explicitly. Monitoring can detect issues continuously while human support operates within a defined service window.
Does a small company need an SLA?
Company size is not the deciding factor. An SLA is useful whenever a slow response or prolonged outage could cause material financial, operational, contractual, or reputational harm.
