A production system goes down at 7:40 on a Saturday evening.
The maintenance agreement says “critical issues receive a four-hour response.”
That sounds clear until the incident actually happens.
Does the four-hour clock run on weekends? What qualifies as critical? Does “response” mean an automated acknowledgement, an engineer beginning investigation or service being restored? What if the maintenance team is waiting for access from the client? What happens if the outage is caused by a third-party platform rather than the application itself?
If the SLA does not answer those questions, the most important parts of the agreement are being negotiated during the incident.
That is exactly what a good service level agreement should prevent.
An application maintenance SLA should define the measurable service commitments surrounding maintenance and support: what is covered, when support is available, how issues are classified, how quickly the provider must respond, how service clocks are calculated, how problems escalate, and what happens when commitments are missed.
It should make expectations measurable without promising outcomes the maintenance team cannot realistically control.
This distinction matters. Microsoft Azure, for example, defines its support commitment around initial response time, not guaranteed resolution time, because the time required to resolve a technical issue depends on the nature and complexity of the problem. Microsoft Azure: Support Scope and Responsiveness
A good app maintenance SLA uses the same discipline: commit precisely where performance can be measured, and avoid vague promises that cannot be enforced consistently.
An SLA should not be responsible for defining the entire maintenance engagement.
The broader scope should already establish which:
are covered.
[Internal Link: “How to Scope an Application Maintenance Engagement”]
The SLA then defines the service commitments around that scope.
For example:
SLA applies to production incidents and defects affecting Application X, its production API and supported integrations. Feature requests, scheduled project work and non-production defects do not carry incident-response targets unless explicitly agreed.
That boundary matters because otherwise routine requests can accidentally inherit the same expectations as production failures.
A new reporting feature should not start a four-hour incident clock merely because it entered the same ticketing system.
A response commitment means very little without a calendar.
Suppose the SLA says:
Severity 2 issues: four-hour response.
If a ticket is submitted at 6 p.m. on Friday, does the deadline fall at 10 p.m. Friday or sometime Monday?
The SLA should explicitly define support coverage.
Common models include:
Business-hours support
For example, Monday–Friday during agreed local hours, excluding defined holidays.
Extended-hours support
Coverage begins earlier or continues later than normal business hours.
24×7 critical support
High-severity incidents receive continuous coverage, while lower-severity work remains within business hours.
Large providers use this distinction themselves. Microsoft Azure ties response commitments both to severity and to the applicable support calendar, with the most critical cases receiving 24×7 treatment while lower-severity support may operate within business hours.
AWS similarly distinguishes support response targets calculated in business hours from round-the-clock technical support under higher-tier plans. AWS Support: Case Management
An app maintenance SLA should be equally explicit.
One of the most important parts of the SLA is the severity matrix.
Avoid definitions such as:
P1 = urgent
P2 = high
P3 = medium
P4 = low
“Urgent” means different things to different people.
Severity should describe the impact on the application and users.
A practical model might look like this:
Severity
Example definition
P1 — Critical
Production unavailable, major data risk, or a business-critical workflow unavailable to a significant portion of users with no viable workaround
P2 — High
Important functionality severely degraded or unavailable, but the application can still operate partially or a temporary workaround exists
P3 — Medium
Limited functionality affected with moderate user impact and a practical workaround
P4 — Low
Minor defect, cosmetic issue or low-impact problem that does not materially prevent normal use
This approach mirrors established support models.
AWS describes higher severity levels in terms of whether important or business-critical application functions are unavailable, while Microsoft's Azure severity model is similarly based on the degree of business loss or service degradation.
The wording should reflect your application, however.
A failed export may be P3 in one system and P1 in another if that export is the only way a business submits a legally required report.
A severity table still creates disputes if anyone can classify their own ticket as critical without review.
The SLA should state:
AWS allows severity to reflect changing urgency and business impact in appropriate support plans, and Microsoft notes that severity can be reduced when the conditions necessary for continuous critical-incident work are no longer present.
A maintenance SLA might therefore say:
Client may assign an initial severity. Provider may adjust classification based on documented business impact after consultation with the client.
That prevents every request from becoming P1 while preserving an escalation route when impact genuinely increases.
One of the easiest SLA metrics to game is “response time.”
A ticket arrives.
Two minutes later, the system replies:
Your request has been received.
Technically, somebody could claim the SLA was met.
Practically, nothing has happened.
Define response as meaningful human engagement.
For example:
Initial response means acknowledgement by an appropriately qualified team member who has reviewed the issue and begun triage or requested information required to proceed.
Microsoft defines initial response time similarly as the period between submitting a support request and a support engineer contacting the customer and beginning work on the request.
This is much stronger than measuring whether an automated ticketing system sent an email.
Once severity and support hours are defined, response targets can be added.
An illustrative table might look like:
Severity
Initial response
Update cadence
P1 Critical
30 minutes
Every 60 minutes while active
P2 High
2 business hours
Every 4 business hours
P3 Medium
1 business day
As material progress occurs
P4 Low
2 business days
Through normal ticket updates
These are examples, not universal recommendations.
The correct targets depend on:
Do not borrow the fastest SLA you can find from a hyperscale cloud provider and assume a small application team can deliver it sustainably.
A commitment is useful only if the operating model can actually support it.
Response time is controllable.
Resolution time often is not.
Consider two P1 incidents.
The first results from a configuration error and can be corrected in fifteen minutes.
The second results from data corruption involving several systems and requires careful investigation, recovery and verification.
Both may have equal business impact while requiring completely different amounts of time to resolve.
That is why major support providers commonly make initial-response commitments without guaranteeing a universal resolution time. Microsoft's support documentation explicitly notes that troubleshooting and resolution duration varies by problem and that mitigation may occur before a complete fix.
If an app maintenance SLA includes resolution targets, define what they mean carefully.
Possible commitments include:
For critical incidents, time to restoration or mitigation is often more useful than promising a permanent code fix within an arbitrary period.
These three outcomes are not interchangeable.
Suppose checkout fails because of a new payment-provider issue.
The maintenance team may:
Service has been restored before root cause has been permanently eliminated.
The SLA should distinguish those milestones where they matter:
Mitigation — impact has been reduced.
Restoration — the affected service or workflow is available again.
Resolution — the underlying incident or defect has been addressed sufficiently to close the case.
This prevents disagreement about whether a workaround means the issue is “resolved.”
The clock normally starts when an issue enters an approved support channel.
State which channels count.
For example:
Do not promise critical response times for messages sent to an individual developer's personal inbox.
The SLA should also define the timestamp used by the service-management system, particularly where teams operate across time zones.
Atlassian's Jira Service Management, for example, calculates SLA timing using an associated SLA calendar and timezone rather than treating all elapsed clock time identically. Atlassian: About Service Level Agreements
Sometimes the maintenance team cannot continue because it is waiting for the customer.
Examples include waiting for:
If that time continues counting indefinitely against the provider, the SLA becomes misleading.
Atlassian's SLA tooling explicitly supports pausing an SLA timer, for example while waiting for a customer to provide additional information.
The agreement should therefore define pause conditions.
A sensible clause might state that resolution clocks pause when progress is blocked solely by information, access or approval required from the client, and resume once that dependency is supplied.
Avoid using pause states as a way to hide slow provider work. They should correspond to genuine external blockers.
An SLA cannot work if obligations exist only on one side.
Customer responsibilities may include:
Microsoft explicitly requires customer participation during its highest-severity incidents; customers selecting critical severity commit to making resources available for continuous work with Microsoft until the situation is resolved or severity changes.
An application SLA can use the same principle.
A provider cannot reasonably commit to continuous P1 investigation if nobody from the client organization is available to answer a business-critical question or approve recovery action.
An SLA should explain what happens when normal support is not enough.
A useful escalation structure might identify:
Operational escalation
Ticket owner or support engineer.
Technical escalation
Senior engineer, architect or specialist.
Service escalation
Maintenance lead or delivery manager.
Business escalation
Named client and provider leadership contacts.
Also define when escalation happens.
Possible triggers include:
The escalation route should not have to be invented during a high-pressure incident.
[Internal Link: “What Does Good Post-Launch Application Support Look Like?”]
A provider may be actively working on a problem while the client believes nothing is happening.
For high-severity incidents, the SLA can include an update cadence.
For example:
For active P1 incidents, the provider will issue a status update at least every 60 minutes until restoration or severity downgrade.
The update should summarize:
Do not require artificial updates every ten minutes if engineers have nothing meaningful to report.
Communication obligations should create confidence without continuously interrupting the people resolving the incident.
Modern applications depend on external providers.
A maintenance team may be able to diagnose a payment-provider outage immediately without being able to fix the provider.
The SLA should state what remains the maintenance team's responsibility during third-party failure.
That can include:
Do not simply exclude every third-party failure from the SLA.
Even if the root cause sits outside the maintenance provider's control, response, diagnosis and communication may remain completely within its control.
At the same time, avoid guaranteeing restoration deadlines dependent on another vendor's systems.
Scheduled maintenance should not normally be measured as unexpected downtime if it occurs within an agreed maintenance window and follows the defined notification process.
The SLA can specify:
This prevents planned database work from being treated as an availability failure while also preventing the maintenance provider from declaring arbitrary outages “planned maintenance” after the fact.
These are related but different.
A maintenance SLA might promise:
P1 incidents receive an initial response within 30 minutes.
An availability SLA might promise:
The application will maintain 99.9% monthly availability.
Those commitments require different measurement.
Google Cloud's SLO documentation defines availability and latency through measurable service-level indicators over defined periods, while its public cloud SLAs attach contractual consequences to missing stated service objectives. Google Cloud: SLO Monitoring Concepts
If availability belongs in the maintenance SLA, define:
Do not include “99.9% uptime” simply because it sounds reassuring.
If nobody can explain exactly how the number will be calculated, it is not a useful SLA.
Reasonable exclusions might include situations such as:
Avoid exclusion language broad enough to make the SLA meaningless.
For example:
SLA does not apply to incidents caused by external systems.
could exclude most serious failures in an application that depends heavily on external services.
It may be more reasonable to exclude guaranteed resolution while maintaining the provider's response and investigation obligations.
An SLA should produce evidence.
Useful monthly reporting may include:
Do not rely only on average response time.
A provider can meet a strong average while repeatedly missing the most critical tickets.
Report the actual SLA target and whether each eligible case met it.
For Levelworks, this relates naturally to Supported App Health: reliable support should be measurable rather than dependent on anecdotes about whether the team “usually responds quickly.”
A service commitment without a consequence is closer to a target than an agreement.
Possible remedies might include:
The appropriate remedy depends on the commercial relationship and should be drafted with appropriate contractual advice.
Do not design penalties that encourage the wrong behavior.
A harsh penalty for missing resolution time, for example, may encourage premature ticket closure rather than better service.
Remedies should reinforce the outcome the SLA is supposed to protect.
An SLA designed for an internal business application with 500 users may no longer fit after the application becomes a customer-facing product operating internationally.
Review the agreement when there are meaningful changes to:
The SLA should evolve when the business consequence of failure changes.
That does not mean renegotiating it every month.
It means refusing to treat service commitments as permanent when the service itself has changed substantially.
Before approving an SLA, make sure it answers these questions:
SLA area
What must be clear
Covered services
Which applications and environments does the SLA apply to?
Support hours
Business hours, extended hours or 24×7?
Severity definitions
What business impact qualifies for each level?
Classification authority
Who assigns and changes severity?
Initial response
What counts as a meaningful response?
Targets
What response commitment applies to each severity?
Resolution
Is it guaranteed, targeted, or replaced with restoration/mitigation commitments?
Clock rules
When does timing start, stop and pause?
Customer obligations
What access, information and participation are required?
Escalation
Who becomes involved when normal handling is insufficient?
Incident updates
How frequently will major incidents be communicated?
Third parties
What happens when an external provider causes the problem?
Maintenance windows
What planned downtime is permitted and how is it communicated?
Availability
If included, exactly how is it measured?
Exclusions
Which circumstances genuinely fall outside the commitment?
Reporting
How will compliance be demonstrated?
Remedies
What happens when commitments are repeatedly missed?
Review
When should the SLA be reassessed?
[Internal Link: “How to Choose an Application Maintenance Company”]
The best SLA may rarely be discussed during normal operation.
Everyone already knows which problems are critical, which clock is running, who owns the next action and what response is expected.
Its value becomes obvious when something goes wrong.
At 7:40 on Saturday evening, nobody should be opening the contract to debate whether support is available, whether the outage qualifies as P1 or whether “four-hour response” means someone will merely acknowledge the ticket.
Those decisions should already have been made.
That is what a useful app maintenance SLA provides: not an impressive table of aggressive numbers, but a shared and measurable definition of how the maintenance relationship behaves when the application needs attention most.
