By Mehdi HassanMost website support agreements fail in the same way. The client thinks "support" means a fix within the hour, and the studio thinks it means a reply within a day. A short, specific SLA prevents that argument. It's one of the documents we'd expect alongside any website maintenance arrangement, and this guide gives you a template you can adapt.
What should a website support SLA include?
A website support SLA should define severity levels, response and resolution targets for each level, support hours, the reporting channel, exclusions and remedies. Everything else is optional. If any of these six is missing, the agreement will be interpreted differently by each side the first time something breaks.
Section | What it answers | Common gap |
|---|---|---|
Severity levels | How urgent is this issue? | Vague words like 'urgent' with no examples |
Response targets | How fast will someone acknowledge it? | Confused with fix time |
Resolution targets | How fast will it be fixed or worked around? | Promised for issues outside the provider's control |
Support hours | When does the clock run? | Time zone and holidays not stated |
Channel and escalation | Where do I report, and who do I call next? | Reports scattered across email, chat and DMs |
Exclusions | What isn't covered? | Third-party outages and client edits left out |
Remedies | What happens if targets are missed? | Penalties that a small team can't absorb |
Keep the SLA itself to one or two pages. The detail of what work is included (updates, backups, content edits) belongs in the scope section of the maintenance contract, not the SLA. If you are still choosing that kind of arrangement, compare a care plan vs a design retainer.
What response times should you expect from website support?
Expect a response within hours for a site that's down and within a business day or two for routine requests, during the provider's stated support hours. Those are the tiers a small studio can actually staff. Agencies with an on-call rotation can promise faster or round-the-clock cover, and usually price it accordingly.
The honest question is what a slow response costs you. A broken demo form on a Monday morning can cost real pipeline. A typo on the about page costs nothing measurable. Price and staff the SLA around the first kind of issue and accept slower handling of the second. Typical arrangements vary widely by provider and price, so treat the template below as a starting point to negotiate from, not a market standard.
A website SLA template with realistic tiers for small studios
This website SLA template uses four severity tiers defined by business impact, with business-hours targets a two-to-five person studio can meet. Adjust the hours to your provider's actual capacity. If a provider agrees to tighter numbers than they can staff, you'll get the same response either way, just with more apologies.
Tier | Definition and examples | Response target | Resolution target |
|---|---|---|---|
P1 Critical | Site down, or the main lead or checkout path broken for all users | Within 2 business hours | Fix or workaround same business day |
P2 High | Key page broken, major visual bug, tracking stopped | Within 4 business hours | Within 2 business days |
P3 Normal | Minor bug, one browser affected, small layout issue | Within 1 business day | Within 5 business days |
P4 Request | Content edits, new sections, small improvements | Within 2 business days | Scheduled into the next work cycle |
Add the support hours under the table, with a time zone (for example, Monday to Friday, 9am to 6pm Eastern, excluding public holidays). If you need weekend cover for P1 only, write that as a separate line with its own price, rather than stretching all tiers to seven days.
Copy-ready SLA clauses
Reporting. All issues are reported through [the agreed channel, such as a shared support email or ticket form]. Issues reported elsewhere start the clock when they're logged in that channel.
Severity. The client proposes a severity when reporting. The provider may reclassify it with a written reason within the response window.
Response. Response means a named team member acknowledges the issue and confirms next steps.
Resolution. Resolution means the issue is fixed or a documented workaround is in place. Resolution targets are goals for issues caused by third-party services, hosting providers or client changes.
Escalation. If a P1 is not acknowledged within the target, the client may contact [named escalation contact] directly.
Review. Both parties review SLA performance [monthly or quarterly] and may adjust tiers in writing.
What should a website maintenance contract exclude?
A maintenance contract should exclude outages caused by third parties, changes the client makes themselves, and new feature work. These exclusions protect both sides. Without them, a studio can be in breach because a payment provider or CMS vendor went down, and the client can't tell where support ends and a new project begins.
- Third-party outages: hosting, CMS, form, analytics or scheduling tools. The provider helps diagnose and communicate, but can't fix someone else's service.
- Client-made changes: edits by the client's team that break layouts. Fixing them is billable or counts against a request allowance.
- New features and redesigns: new pages, templates or integrations go through a separate quote or retainer scope.
- Content accuracy: the client owns the truth of prices, claims and legal text.
- Security incidents caused by leaked credentials on the client side, though the provider should still help respond.
List the services you depend on in an appendix. It makes exclusions concrete, and it doubles as the starting point for your ongoing running costs.
How do you measure and enforce a website support SLA?
Measure the SLA from timestamps in one shared channel, and enforce it with reviews and service credits rather than heavy penalties. If reports arrive by text message, nobody can prove when the clock started. A shared support inbox, ticket form or dedicated chat channel gives both sides the same record.
Pick one reporting channel
A support email, a ticket form or a dedicated chat channel. Everything else gets redirected there.
Log severity and timestamps
Record when each issue arrived, when it was acknowledged and when it was resolved. Most help desks do this automatically.
Pair it with monitoring
Automated checks catch P1s before the client does. Our guide to website uptime monitoring covers a one-hour setup.
Review on a schedule
Look at misses monthly or quarterly. Repeated misses usually mean the tier definitions or staffing need to change.
Use service credits sparingly
A modest credit against next month's fee for a missed P1 is fair. Large penalties push small studios to refuse SLAs entirely.
Does a design retainer need an SLA?
A design and development retainer needs a light SLA for breakages and a planning rhythm for everything else. Retainers are mostly about new work: pages, experiments and improvements. Treating each of those as a ticket with a timer makes the work worse. The SLA should cover what breaks, and the roadmap should cover what's built.
That's how we run our own retainer. Our monthly retainer is $6,000 a month for an ongoing design and development team that joins your customer calls, with no hourly tracking. Response expectations for issues are agreed at the start, and new work is planned together instead of rationed by hours. If you're weighing that against a lighter care plan, see who updates your website after launch and what maintenance costs.
Which website SLA mistakes should you avoid?
The costly mistakes are promising 24/7 without a rotation, skipping exclusions, and forgetting access. A provider can't fix a P1 in two hours if they don't have DNS, hosting and CMS access, so list required access in the contract and check it at kickoff.
- No time zone: a 4-hour response means nothing if one side is 9 hours ahead.
- No escalation contact: if the main contact is sick, a P1 waits.
- No review clause: the site changes, but the SLA tiers never do.
- Mixing project scope into the SLA: new pages on a migration plan or redirects from a redirect map are project work, not support tickets.
