Most website problems don’t start with bad code. They start with fuzzy ownership.
The site goes down. The host says the server is fine. The web designer says maintenance wasn’t included. The marketing manager can’t find the DNS login. The owner wants to know why nobody answered the support email for six hours.
That’s an SLA problem.
A website service level agreement, usually called an SLA, tells everyone what “support” actually means. It defines uptime targets, response times, escalation rules, backup expectations, security responsibilities, reporting, and what happens when the vendor misses the standard.
This guide gives you a practical website SLA template for small businesses, freelancers, and agencies. It is not legal advice. Have an attorney review anything tied to revenue, regulated data, customer contracts, or penalties. But if your current website support agreement is just “email us if something breaks,” this will make your business safer.
Quick website SLA scorecard
Use this scorecard before you sign a hosting, maintenance, web design, or support agreement.
| SLA area | Green flag | Red flag |
|---|---|---|
| Uptime | Target, measurement method, exclusions, and remedy are written down | ”Reliable hosting” is the whole promise |
| Monitoring | Critical pages, forms, SSL, DNS, and payment flows are checked | Vendor only knows when you complain |
| Response times | Severity levels have response targets | Every ticket goes into the same inbox |
| Backups | Frequency, retention, location, and restore tests are defined | Backups are assumed but never tested |
| Security | Updates, vulnerability handling, passwords, WAF, and incident process are assigned | ”Security included” with no details |
| Ownership | Domains, hosting, analytics, code, licenses, and accounts are named | Vendor controls access without a handoff clause |
| Reporting | Monthly or quarterly reporting shows uptime, incidents, changes, and risks | No one reviews what happened |
The value of an SLA is not paperwork. The value is that it removes guessing when revenue, reputation, or customer access is on the line.
Why small businesses need website SLAs now
Small business websites are more operational than they used to be. A local service company may depend on form leads, booking tools, call tracking, Google Business Profile traffic, online reviews, CRM integrations, live chat, payment links, and recruiting pages. When the website fails, the business does not just lose design polish. It loses pipeline.
Downtime has a measurable cost. Network Solutions reported that small and midsize businesses can lose around $2,500 per month during an average of 5 hours of downtime. Uptime targets also sound more generous than they are. A 99.9% uptime target allows about 8 hours and 46 minutes of downtime per year, while 99.99% allows about 52 minutes and 36 seconds per year.
Security risk is part of the same conversation. Patchstack reported 11,334 new vulnerabilities in the WordPress ecosystem in 2025, a 42% increase from the prior year. CISA tells small and medium businesses to use the 3-2-1 backup rule because recovery depends on having clean, reachable copies when systems fail or get compromised.
An SLA does not prevent every outage. It does make sure the right person is watching, the right system is backed up, and the right decision maker gets called before a small incident becomes a bad week.
Website SLA template
Copy this structure into your agreement, proposal, statement of work, or maintenance plan. Change the numbers to match the real business risk. A dentist with online booking does not need the same SLA as an ecommerce store doing thousands of transactions per day.
1. Services covered
Start by naming the systems covered by the SLA.
Example clause:
This SLA covers the public website at example.com, the production hosting environment, CMS updates, contact forms, booking forms, SSL certificate, DNS records managed by the provider, website backups, uptime monitoring, security monitoring, analytics tags installed by the provider, and launch-critical integrations listed in Appendix A.
Do not use vague language like “website support” without a system list. A support provider cannot be accountable for a payment processor, CRM, domain registrar, or email platform if those systems are not named and access is not granted.
Include exclusions too. If the provider does not manage email hosting, paid ad accounts, third-party CRM outages, custom client-side scripts installed by the client, or legal compliance review, say so.
2. Uptime target
A realistic uptime clause needs four parts: target, measurement tool, measurement window, and exclusions.
Example clause:
Provider will use commercially reasonable efforts to maintain 99.9% monthly uptime for the production website, measured by the agreed monitoring tool from at least three geographic locations. Scheduled maintenance, third-party platform outages, DNS registrar failures outside provider control, client-caused outages, and force majeure events are excluded from uptime calculations.
For many small business lead generation sites, 99.9% monthly uptime is a reasonable starting point. If the site processes transactions, supports urgent customer service, or handles booked appointments, discuss 99.95% or 99.99% with the hosting provider. Do the math before promising more. A 99.99% target leaves only 4 minutes and 23 seconds of downtime per month, which may require better hosting, monitoring, deployment controls, and incident coverage.
Do not let uptime be measured only by whether the homepage responds. A site can be technically “up” while the contact form, checkout, booking widget, or quote request flow is broken.
3. Critical path monitoring
Monitoring should follow money and trust.
Example clause:
Provider will monitor the homepage, primary service page template, contact form confirmation path, booking path, checkout path if applicable, SSL certificate status, DNS resolution, robots.txt availability, sitemap availability, and server response status. Alerts will route to the provider’s support channel and the client emergency contact for SEV1 incidents.
Google’s Core Web Vitals documentation says site owners should aim for LCP within 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. Those are user experience targets, not uptime targets, but they belong in your SLA reporting if website performance is part of the support plan.
For small businesses, the most useful monitoring checks are usually simple: is the site loading, is SSL valid, is the form submitting, is the thank-you page firing, is the checkout reachable, and did the site suddenly start returning errors?
4. Severity levels and response times
Every support ticket should not get the same clock.
Example severity table:
| Severity | Definition | Examples | Response target | Update cadence |
|---|---|---|---|---|
| SEV1 | Revenue, security, or public trust is actively at risk | Site offline, hacked page, checkout down, data exposure, DNS failure | 30 minutes during coverage hours | Every 60 minutes |
| SEV2 | Major function broken with workaround | Lead form down, booking tool down, major template error | 4 business hours | Daily until resolved |
| SEV3 | Visible issue with limited impact | Broken image, layout issue, analytics tag error | 2 business days | At milestone updates |
| SEV4 | Low-priority request | Copy edit, minor content update, enhancement | Normal queue | As scheduled |
Atlassian defines incident metrics like mean time to acknowledge and mean time to resolve because response speed and recovery speed are different. Your SLA should track both. A vendor can answer quickly and still take too long to fix the problem.
Be clear about coverage hours. If the plan is business-hours support, say so. If emergency coverage exists after hours, name the phone number, escalation path, and fee.
5. Backup and restore requirements
Backups are only useful if they can be restored.
Example clause:
Provider will maintain daily production backups, retain at least 30 days of restore points, store backups separately from the production hosting account, and perform a documented restore test at least quarterly. Provider will confirm successful backup status in the monthly report.
CISA recommends the 3-2-1 backup rule: keep three copies of data, on two different media or platforms, with one copy offsite. For websites, that usually means production files and database, a hosting-level backup, and a separate offsite backup controlled through a backup system or storage provider.
Set restore time expectations too. A five-minute backup is not the same thing as a five-minute recovery. If a WordPress site has malware, restoring the latest backup may restore the infected files. The SLA should say who validates the restore point and who approves putting the site back online.
6. Security responsibilities
Security clauses work best when they separate vendor duties from client duties.
Example provider duties:
Provider will apply CMS, theme, and plugin updates according to the approved maintenance schedule, monitor known vulnerabilities for supported components, maintain least-privilege access for provider users, require multi-factor authentication where supported, and notify client of critical security risks that require client approval or paid remediation.
Example client duties:
Client will use unique passwords, enable multi-factor authentication where supported, avoid installing unapproved plugins or scripts, notify provider before changing DNS or hosting settings, and maintain access to domain, hosting, payment, CRM, and email accounts.
This matters because WordPress risk is often tied to the wider plugin and theme ecosystem. Patchstack’s 2026 security whitepaper reported 11,334 new WordPress ecosystem vulnerabilities in 2025. If nobody owns updates, testing, and emergency mitigation, the site gets weaker every month.
Do not promise perfect security. Promise specific controls, fast escalation, clean access practices, and documented response.
7. Change management
Many outages happen during ordinary updates, launches, DNS edits, plugin changes, content pushes, and tracking script installations.
Example clause:
Provider will perform material production changes through a documented change process. Changes that affect templates, DNS, payment, forms, redirects, caching, tracking, or authentication will include a rollback plan. Client-requested emergency changes may bypass normal scheduling with written approval from the client decision maker.
For small sites, change management does not need enterprise software. A shared ticket, timestamped note, staging link, screenshot, backup confirmation, and rollback instruction are often enough.
The key is discipline. If a change can block leads, payments, search indexing, or customer trust, it deserves a record.
8. Reporting and review
An SLA should create a feedback loop, not just a promise.
Example clause:
Provider will send a monthly SLA report showing uptime percentage, incidents, response times, unresolved risks, completed updates, backup status, security notices, Core Web Vitals status where available, and recommended improvements.
Report the few numbers that business owners can use. Uptime percentage, downtime minutes, number of incidents, average acknowledgment time, average resolution time, backup success, failed form tests, unresolved security risks, and open client dependencies are enough for most small businesses.
If the site is important to lead generation, include conversion-critical checks. Did the form work? Did call tracking fire? Did organic traffic drop? Did the top service pages stay indexable? Google Search Console’s Core Web Vitals report groups URLs by LCP, INP, and CLS based on field data, so it can help separate isolated lab test problems from real user experience issues.
9. Remedies when the SLA is missed
Remedies keep the SLA honest.
Example clause:
If provider misses the uptime target or response target for reasons within provider control, client may receive a service credit equal to the affected portion of the monthly support fee. Repeated SLA misses may trigger a required service review, corrective action plan, or termination right under the agreement.
For small business website support, service credits are usually modest. The bigger remedy is a required review and corrective action plan. If the site goes down because the provider failed to renew SSL, ignored alerts, or pushed a bad update without a rollback plan, you need process correction, not a $40 credit.
Also define what does not count as an SLA breach. Client-caused DNS changes, unpaid invoices that pause service, third-party outages, registrar locks, missing approvals, and unapproved plugins should not become vendor liability without limits.
10. Access, ownership, and exit
The worst time to discover you do not control your website accounts is during a dispute or outage.
Example clause:
Client will retain ownership or administrative access to domain registration, hosting account, CMS administrator account, analytics, Search Console, source code repository where applicable, paid licenses purchased by client, and brand assets. Provider will deliver an exit handoff within 10 business days of termination, subject to payment of undisputed amounts due.
This clause protects both sides. The client avoids being trapped. The provider avoids being blamed for accounts it cannot access.
Name the account owner for each system. Domain registrar, DNS, hosting, CMS, CDN, email sending service, payment processor, CRM, analytics, tag manager, repository, plugin licenses, font licenses, stock assets, and backup storage all deserve a line item.
Recommended SLA levels by website type
Use these as starting points, not promises.
| Website type | Uptime target | Monitoring | Support response |
|---|---|---|---|
| Brochure site | 99.5% to 99.9% | Homepage, contact page, SSL, forms | Same business day for major issues |
| Lead generation site | 99.9% | Service pages, forms, thank-you pages, call tracking, SSL | 4 business hours for SEV2, faster for SEV1 |
| Booking or appointment site | 99.9% to 99.95% | Booking path, confirmations, payment links, forms | 30 to 60 minutes for SEV1 |
| Ecommerce site | 99.95% to 99.99% | Checkout, cart, payment, order emails, inventory sync | 15 to 30 minutes for SEV1 |
| Membership or customer portal | 99.9% to 99.99% | Login, account pages, payment, support path | Depends on customer contract risk |
Higher targets cost more because they require better infrastructure, monitoring, coverage, testing, and response. That is not vendor greed. That is how uptime works.
Website SLA questions to ask before signing
Ask these before you buy maintenance, hosting, or a redesign package:
- What exact systems are covered by support?
- What uptime target is promised, and who measures it?
- Which pages and user paths are monitored?
- What are the SEV1, SEV2, SEV3, and SEV4 response targets?
- Are response times measured during business hours or 24/7?
- Where are backups stored, and how often are restores tested?
- Who applies CMS, plugin, theme, and dependency updates?
- What happens if an update breaks the site?
- Who owns the domain, hosting, analytics, Search Console, and source code?
- What report will we receive each month?
- What service credit, review, or termination right applies if targets are missed?
If a vendor answers clearly, that is a good sign. If every answer is “don’t worry, we’ve got it,” keep asking.
FAQ: Website SLAs
Is a website SLA only for big companies?
No. Small businesses need SLAs when the website supports leads, bookings, payments, hiring, support, or reputation. The SLA can be simple, but ownership, response times, backups, and escalation paths should still be written down.
What is a good uptime SLA for a small business website?
For a normal lead generation site, 99.9% monthly uptime is often a practical starting point. Ecommerce, booking, and customer portal sites may need 99.95% or 99.99%, but those targets should come with better hosting, monitoring, and emergency coverage.
Should website performance be included in the SLA?
Yes, if performance is part of the service. Use Core Web Vitals, page weight, uptime, and critical path checks as reporting metrics. Do not treat a single lab test as the whole SLA because real users, devices, and traffic sources vary.
Who should own the website SLA?
One business contact should own the SLA internally, and one provider contact should own it on the vendor side. Without named owners, support becomes a shared inbox where urgent issues get treated like routine edits.
Make the SLA match the business risk
A website SLA is not about making your vendor nervous. It is about making the operating rules visible.
If your website is a brochure, keep the SLA simple. If it drives quote requests, appointments, online orders, recruiting, or customer support, tighten the standards. Name the systems. Monitor the critical path. Test the backups. Track the response clock. Review the report.
Your website does not need a 40-page legal document to be managed well. It does need clear promises that survive the first outage.
If you want help turning your current website support plan into a practical SLA, get started here. We’ll help you find the gaps before customers do.
