Website Maintenance SLA Template for Web Agencies

August 8, 2026 · 7 min read

A website maintenance SLA should define the covered service, support hours, severity rules, response and communication targets, monitoring evidence, maintenance windows, client obligations, third-party dependencies, exclusions, reporting, and review process. It should distinguish what the agency can control from what it only coordinates.

Do not promise “resolution in two hours” for every critical incident if recovery depends on a hosting provider, registrar, payment platform, or client approval. Commit first to acknowledgement, active response, mitigation effort, escalation, and update cadence.

This guide provides operational structure, not legal advice. Have qualified counsel adapt the agreement to the parties, jurisdictions, data, insurance, tax, consumer, employment, and sector requirements.

At a glance

A usable SLA answers:

1. Which websites, environments, and dependencies are covered?
2. When is support available and in which time zone?
3. How are incidents reported and when does the clock start?
4. What do P1–P4 mean for this client?
5. What are acknowledgement, response, update, mitigation, and resolution targets?
6. Which monitoring source is authoritative for measurement?
7. How are planned maintenance and client-caused delays treated?
8. Who may approve emergency changes?
9. What must the client provide?
10. How are exceptions, service credits, or remedies handled?
11. What evidence and report will the agency deliver?
12. How often is the SLA reviewed?

SLA, SLO, and SLI in agency language

• SLI: a measured indicator, such as checkout success rate or external availability.
• SLO: an internal or agreed objective for that indicator.
• SLA: a contractual commitment and its measurement/remedy framework.

An agency may use a stricter internal SLO than the contractual SLA to leave operating margin.

Define clocks precisely

Clock	Starts	Stops
Detection	first measurable impact	monitoring receives signal
Acknowledgement	valid request/alert received	ownership confirmed
Response	incident confirmed/declared	qualified work begins
Mitigation	incident declared	material impact reduced or workaround available
Resolution	incident declared	agreed recovery criteria met
Communication	update trigger	approved update sent

State whether clocks run only during service hours or continuously, how duplicate reports are merged, and how waiting for required client action is recorded.

Example service-level table

Severity	Example impact	Coverage	Acknowledge	Active response	Update cadence	Resolution commitment
P1	Critical journey unavailable or serious active security/data risk	24/7 if purchased	15 min	30 min	30 min	Best efforts + agreed escalation; target only if supportable
P2	Major degradation or contained outage	Contract schedule	30 min	1 hour	60 min	Target by service design
P3	Limited non-critical failure	Business hours	4 business hours	1 business day	At milestones	Planned target
P4	Cosmetic/improvement	Business hours	1 business day	Scheduled	Normal workflow	Backlog/change request

These numbers are examples. Calculate staffing, on-call cost, client criticality, vendor contracts, and historical workload before offering them.

Availability measurement

A basic monthly availability calculation is:

availability = (measurement window - counted downtime) / measurement window × 100

The formula is useless without definitions:

• which URL, journey, or service is measured;
• which locations and frequency;
• confirmation and timeout rules;
• whether partial degradation counts;
• planned maintenance treatment;
• third-party and client-controlled dependency treatment;
• minimum incident duration;
• source of truth and dispute procedure;
• rounding and report period.

For a lead-generation site, form delivery may be a more meaningful service indicator than homepage uptime alone.

Copyable operational SLA schedule

# Website maintenance service level schedule

Version: [number]
Effective date: [UTC date]
Service provider: [agency legal entity]
Client: [client legal entity]
Related agreement: [reference]

## 1. Covered services
- Production websites: [URLs]
- Staging/test: [scope]
- Included components: [CMS, code, hosting coordination, DNS, CDN, monitoring]
- Critical journeys: [list and success conditions]
- Included integrations: [list]
- Excluded services: [explicit list]

## 2. Service hours
- Standard hours: [days/hours/time zone]
- On-call coverage: [scope]
- Holidays: [calendar/reference]
- Emergency reporting channel: [channel]
- Routine reporting channel: [help desk]

## 3. Severity
The parties use the P1–P4 definitions in [policy/version].
Severity is based on current impact, scope, workaround, and data/security risk.
Reclassification is recorded with timestamp and reason.

## 4. Service targets
[Insert agreed table for acknowledgement, response, updates, mitigation, resolution.]

## 5. Clock rules
- Clock starts when: [valid alert/request condition]
- Duplicate reports: [rule]
- Awaiting client/vendor: [recording rule]
- Out-of-hours P2–P4: [rule]
- Time source: [UTC/system]

## 6. Monitoring and evidence
- Source of truth: [system/check IDs]
- Measurement locations: [regions]
- Frequency and confirmation: [values]
- Retention: [value]
- Monthly evidence: [report fields]

## 7. Planned maintenance
- Standard window: [value]
- Notice: [value]
- Emergency maintenance authority: [role]
- Maximum suppression: [value]
- Post-change checks: [reference]

## 8. Client responsibilities
- Maintain authorised contacts and approvals.
- Keep vendor accounts funded and licences current unless delegated.
- Provide timely access and accurate system information.
- Notify the agency of third-party changes and campaigns.
- Protect client-controlled credentials and devices.
- Approve risk, downtime, or expenditure within [target].

## 9. Dependencies and exclusions
- Third-party providers: [treatment]
- Client or other-supplier changes: [treatment]
- Unsupported software: [treatment]
- Force majeure and legal exclusions: [counsel-reviewed clause]
- Security incident response: [separate plan/reference]

## 10. Reporting and review
- Monthly report: [date and contents]
- Incident report trigger: [criteria]
- Service review: [cadence]
- SLA change process: [process]

## 11. Remedies
[Counsel-reviewed credits, caps, exclusions, and claim process.]

Accepted by authorised representatives: [signatures/process]

Third-party dependencies

Avoid the two extremes:

• “all provider outages are excluded,” which leaves the client without coordination;
• “the agency guarantees every provider,” which creates an uncontrollable promise.

A practical allocation may say the agency does not control the provider's restoration time but does commit to detection, escalation, workaround assessment, evidence gathering, and client updates.

Client responsibilities matter

Examples include:

• domain and vendor renewals;
• maintaining authorised contacts;
• approving emergency spend or risky recovery decisions;
• notifying the agency of campaigns and third-party changes;
• providing correct test accounts and privacy rules;
• using the help desk instead of private messages to individuals;
• funding a support level appropriate to the required coverage.

If the client must approve rollback but no approver can be reached, the SLA should describe the authorised fallback.

Planned maintenance

Define standard windows, notice, expected impact, approval, rollback, monitoring suppression, and validation. An unannounced production change is not automatically planned maintenance just because the engineer intended it.

SLA reporting

Report more than a single percentage:

• measured service and period;
• incidents by severity;
• detection, acknowledgement, mitigation, and recovery times;
• affected journey and user impact;
• excluded windows with reasons;
• repeated failure patterns;
• monitoring gaps;
• action items and owner;
• one prioritised recommendation.

Example: why 99.9% can mislead

A store may exceed a homepage availability target while checkout fails for six peak hours. Conversely, a two-minute monitoring failure from one location may not represent customer downtime. The solution is not to abandon availability but to pair it with critical-journey indicators and explicit measurement rules.

Common SLA mistakes

• copying enterprise response targets without staffing for them;
• mixing acknowledgement and resolution;
• measuring only the homepage;
• omitting time zones and holiday calendars;
• promising systems controlled by other providers;
• having no client approval fallback;
• defining severity differently in the contract and incident playbook;
• excluding so much that the SLA has no operational value;
• treating the template as legal advice.

FAQ

Does an SLA guarantee uptime?

An SLA defines commitments, measurement, responsibilities, and remedies. It cannot make failure impossible.

Should every maintenance plan include 24/7 response?

No. Coverage should match business criticality, staffing, price, and dependency support. Be explicit about out-of-hours treatment.

Can an agency stop the SLA clock while waiting for the client?

Only under clearly agreed rules, with evidence that the required action and deadline were communicated. Local counsel should review contractual treatment.

Should uptime be measured by the hosting provider or the agency?

Define the source of truth. Independent external monitoring can reduce disputes, but its configuration and limitations must also be documented.

Sources and further reading

• Google SRE: Managing Incidents
• AWS Well-Architected Reliability Pillar
• NIST SP 800-61 Rev. 3

Reviewed: 8 August 2026.

Next: Critical user journey monitoring and client website inventory.

Pingvera can provide independent external evidence for selected SLA indicators. Confirm the exact service, check configuration, and retention before naming any monitoring source in a contract.

Read next: Monthly Website Maintenance Report: Template & Checklist · Web Agency Access Control Matrix Template · Accidental Noindex: How Agencies Detect It Fast · Ecommerce Unit Economics: Practical Template · Run a free site check.