Maintenance SLA Example
See how a website maintenance agreement defines priorities, response times and exclusions so that both sides can check what was promised.
1 Overview
A maintenance SLA is the part of a maintenance contract that turns "we look after your website" into commitments someone can check. It says which work is included in the monthly fee, how fast the provider reacts when something breaks, how fast the problem has to be fixed, what is not covered, and how the provider proves each month that the targets were met. Without it, both sides rely on memory and goodwill, and the first serious outage becomes an argument about what was agreed.
What the document must contain
- Covered services. A concrete list: updates of the CMS, framework and plugins, security patches, backups and restore tests, uptime monitoring, defect fixes, and usually a small budget of hours for minor changes. Name the systems covered, for example the shop but not the newsletter tool.
- Priority levels. Three or four levels, each defined by business impact and illustrated with examples from your own site. "Checkout does not work" is a useful definition, "serious problem" is not.
- Response and resolution times. Response time is the time until a qualified person confirms the ticket and starts working. Resolution time is the time until the fault is fixed or a workaround is in place. Both need a number per priority.
- Service hours. Times only mean something together with the hours in which the clock runs. A four-hour target counted in business hours can end the next morning.
- Reporting channel. Where tickets are sent, who may send them and what information a ticket needs.
- Exclusions. Work that is billed separately or not offered at all.
- Reporting. What the monthly report shows and when it arrives.
- Consequences. What happens when a target is missed, and how the agreement is reviewed and ended.
How to read the times
Ask three questions for every number. When does the clock start: at the moment of the email, or when the provider confirms it? When does it pause: while the provider waits for your answer, or while a third party such as the hosting company works on its part? And what counts as resolved: a permanent fix or a workaround that restores the function? A good SLA answers all three in writing.
Common mistakes
- Only a response time is agreed. A fast reply that says "we are looking into it" does not help if no resolution target follows.
- Priorities are left to the provider alone. Agree who sets the priority and how a disagreement is settled.
- Exclusions are missing. Then every feature request is treated as maintenance by one side and as a new project by the other.
- Uptime is promised by someone who does not run the server. If hosting is with a third party, the maintenance provider can commit to monitoring and reaction, not to availability.
- Backups are listed but restores are never tested. Ask for a restore test and its result in the report.
- The hour budget is unclear. State whether unused hours expire and what an extra hour costs.
- Nobody reads the report. Plan a short review every quarter and adjust priorities and times to what really happened.
Before you sign
Check that the targets fit your business. A shop that sells at the weekend needs a rule for Saturday and Sunday; a brochure site usually does not, and paying for standby it will not use is wasted money. Tighter times cost more, because someone has to be available. Liability limits, service credits and termination clauses have legal consequences, so have those parts checked by a lawyer before signing.
2 Example
The excerpt below is from an invented maintenance agreement between a small online garden shop and its web studio. All names, times, fees and percentages are illustrations, not recommendations or market prices.
Service Level Agreement: Website Maintenance (excerpt)
Client: Tarnwick Garden Supply Ltd, represented by Odette Marlowe, Operations Manager
Provider: Quillmere Web Studio, represented by Ruben Castellan, Lead Maintainer
Valid from 1 January 2027, version 1.2
1. Covered systems
This agreement covers the online shop and the blog on the same installation, including the staging copy. It does not cover the newsletter tool, the warehouse software or the client's email accounts.
2. Covered services
- Monthly updates of the shop system, theme and plugins, tested on staging first
- Security patches rated critical by the vendor, applied within 2 business days of release
- Daily backup of files and database, kept for 30 days, with one restore test per quarter
- Uptime monitoring every 5 minutes with alerts to the provider
- Fixing defects in the covered systems
- Up to 4 hours per month for small changes requested by the client. Unused hours expire at the end of the month. Further hours are billed at 95 pounds per hour after written approval.
3. Service hours and reporting channel
Service hours are Monday to Friday, 08:00 to 18:00, excluding public holidays. Tickets are sent to the support address or, for priority 1, reported by phone. Tickets may be opened by Odette Marlowe and two named deputies.
4. Priorities, response and resolution times
- Priority 1, critical: the shop is unreachable or customers cannot pay. Response within 1 service hour, fix or workaround within 4 service hours.
- Priority 2, high: an important function fails but a workaround exists, for example one payment method is down. Response within 4 service hours, resolution within 2 business days.
- Priority 3, normal: a defect with little business impact, for example a layout error on one page. Response within 1 business day, resolution within 10 business days.
- Priority 4, request: questions and small changes. Response within 2 business days, delivery date by agreement.
Outside service hours, monitoring alerts for priority 1 are answered within 3 hours between 07:00 and 22:00 on every day of the year.
The client proposes the priority and the provider confirms it. If they disagree, Odette Marlowe and Ruben Castellan decide together on the same business day; until then the higher priority applies.
The clock starts when the ticket arrives and pauses while the provider waits for information from the client or for a third party to act.
5. Exclusions
- New features, redesigns and content entry
- Faults at the hosting company, the payment provider or other third parties. The provider reports and coordinates these, but resolution times do not apply.
- Defects caused by changes the client made to code, or by plugins installed without agreement
- Training of client staff
6. Reporting
By the 5th business day of each month the provider sends a report with: measured uptime, tickets by priority with actual response and resolution times against target, updates applied, backup and restore test results, hours used from the budget, and recommendations. Both parties review the reports in a 30-minute call every quarter.
7. Missed targets
For each missed priority 1 or priority 2 target, the client receives a credit of 5 percent of the monthly fee, limited to 20 percent per month.
3 Who this is for
Founder
You see which promises a maintenance contract should contain before you sign one, and which questions to ask about response times, weekend cover and the hour budget so that the monthly fee buys what your business needs.
IT manager
You get a structure for priorities, clock rules and monthly reporting that you can compare with a provider's draft, and a list of the gaps that typically cause disputes after the first outage.
Procurement lead
You can compare offers from several providers line by line: covered services, service hours, response and resolution targets, exclusions and what happens when a target is missed.
4 Questions and answers
What is the difference between response time and resolution time?
Response time is how long it takes until a qualified person confirms your ticket and starts working on it. Resolution time is how long it takes until the fault is fixed or a workaround restores the function. An SLA that only states response times promises a quick reply, not a working website, so ask for both figures per priority.
Should a maintenance SLA guarantee uptime?
Only if the provider also controls the hosting. A maintenance provider working on a server run by a third party can commit to monitoring, to reacting within a set time and to coordinating with the host. The availability figure itself belongs in the hosting contract. If one company does both, an uptime target and the way it is measured should be written down.
Can I use this example as my own contract?
Use it as a checklist and as a starting point for discussion, not as a finished contract. The figures are invented for illustration and have to be replaced by what your business needs and your provider can deliver. Clauses on liability, service credits and termination should be reviewed by a lawyer.
Planning a project like this?
Tell us what you are building. You get a straight answer on scope, approach and effort.