Website SLA support: what it must include and how to verify it
9 min read
Website Support SLAs: What They Need to Cover and How to Verify Them
An SLA for website support is a contractual document that binds a provider to specific response times, resolution targets, and an availability percentage. An SLA isn't a marketing promise — it's a measurable agreement, so check three things first: support hours, escalation rules, and reporting commitments.
In short:
For P1 issues, require a response within a few hours, resolution the same day, and updates every 30 minutes; for P2, updates should come every two hours.
The contract should separate response time from resolution time, define targets for priority classes P1 through P4, and specify penalties and exceptions for outages outside the provider's control.
For planned maintenance, require at least 48 hours' notice and a contractual definition of windows excluded from availability calculations.
Before signing, request the monthly number of included hours, the price of additional work, rules for pausing the clock while waiting on you, and regular response reports.
Hosting and domain registration are often separate services; also check whether the package covers content changes, security updates, or just minor fixes.
Moxy-webmoxy-web.comSupport for a reliable websiteMoxy-web offers technical support and website maintenance, along with hosting and domain registration.Explore Moxy-web's services
Table of Contents
A priority matrix: a practical model for classifying incidents
Proactive monitoring, maintenance, and planned downtime in an SLA
How to choose a support provider, and which clauses to include in the contract
What an SLA needs to cover: key components and metrics
A good SLA keeps three concepts separate that providers often blur together: response time, resolution time, and availability. As a formal contract, an SLA sets expected service levels and response and remediation steps, and serves as a benchmark for accountability during outages. Response time tells you how quickly a provider contacts you after you report an issue; resolution time tells you how long it takes to actually fix it. Availability is the percentage of time a site runs without outages, and it's typically expressed as a very high value, often close to full availability.
Before signing a contract, also check these elements:
which priority classes (P1 through P4) the contract distinguishes, and what targets apply to each
whether penalties or compensation are specified if the provider misses its targets
which situations are excluded from the provider's obligations (third-party limitations, force majeure, hosting issues outside their control)
A priority matrix: a practical model for classifying incidents
Impact and urgency together determine an incident's priority. A priority matrix translates a problem's business impact and urgency into operational classes from P1 to P4, each with its own response and resolution target. An entire online store being down is typically P1, while a minor cosmetic glitch on a subpage is P4.
P1, critical: the site or store is down for all visitors; respond within a few hours, resolve the same day.
P2, high: an important feature isn't working (the payment module, say); respond the same business day.
P3, medium: a minor bug affects some users; resolve within a few business days.
P4, low: cosmetic or content fixes; resolve on an agreed-upon schedule.
A common mistake is a provider promising fast response targets without actually having an on-call team capable of meeting them outside regular business hours. A recommended communication cadence for P1 incidents is an update every 30 minutes, and every two hours for P2 — worth building into the contract.
Pro tip: Always check that priority targets align with the actual support schedule, not just a general "24/7" promise.
Support tiers, and separating front-end from back-end tasks
Support packages mainly differ in the number of included hours and which tasks fall under the base price. A basic package usually covers security updates, performance monitoring, and minor content fixes. An advanced or VIP package adds faster response targets, more included hours for development changes, and direct access to a dedicated support contact.
When choosing a package, pay attention to how work is divided:
content management (adding text, images, blog posts) is usually part of every package
bug fixes and security updates fall under technical maintenance, which we describe in our guide to website maintenance
hosting and domain registration are usually a separate service, not part of a support SLA
Always require the contract to specify an exact number of included hours per month and the price for additional work beyond that limit, otherwise you'll be caught off guard at the first substantial piece of work.
Proactive monitoring, maintenance, and planned downtime in an SLA
A well-designed SLA separates unplanned outages from maintenance windows a provider announces in advance. Planned maintenance — a server update or a major system change, say — is typically excluded from the availability calculation if it was communicated in time.
It's worth including these requirements in the contract:
notice of planned maintenance at least 48 hours in advance
a clear definition of which windows count as "scheduled maintenance" and are excluded from the uptime calculation
automated performance monitoring that catches problems before users report them
Examples from industry SLA documents show that availability targets are often expressed as 99.9% or 99.95%, with contractual service credits if the provider misses them. An example of this approach shows that measurable availability is a standard practice beyond websites too, and it's worth carrying over into the SLA for your own site. We explain the process behind monitoring like this in more detail in our description of how website maintenance works.
How to choose a support provider, and which clauses to include in the contract
Before signing an SLA, vet the provider with a set of concrete questions, then require the answers to become part of the contract, not just a verbal assurance.
What are the support hours, and is there an on-call team for urgent issues outside those hours?
What are the exact response and resolution targets for each priority, from P1 to P4?
How does escalation work if the first support tier doesn't resolve an issue within the agreed timeframe?
When does the resolution "clock" pause — while waiting for your response, say, or for a third party's access?
Stop-clock rules are an often-overlooked clause, but they're exactly what prevents disputes when resolution drags on due to circumstances the provider can't control. Also require regular reports on actual response times, since this proves the SLA is being honored in practice, not just signed on paper.
Pro tip: Ask to see a past SLA report before signing the contract, since it tells you more than any sales pitch.
How we structure website support at Moxy
After completing a website build, we set up a dedicated support contact and regular maintenance, which includes security updates, performance monitoring, and content fixes. Our onboarding process is designed so the client knows, from day one, who to contact and what to expect. For concrete examples of what this looks like in practice, see our description of support that actually works and our overview of what monthly maintenance includes.
Common SLA mistakes, and how to avoid them
The biggest mistake is believing an SLA alone fixes technical problems — an SLA is an administrative and communication framework that requires consistent reporting. Response targets are often set too high relative to actual staffing, or the boundaries of accountability are left vague, with no stop-clock rules. I'd recommend always aligning targets with the team's real capacity and requesting a short trial onboarding before signing a long-term contract.
— Ziga
Website support and maintenance at Moxy
We treat maintenance and support as a continuation of building the site, not a separate service, so every project gets a dedicated contact who knows your site from day one. Under our Support & Maintenance service, we handle security updates, performance monitoring, and fast resolution of urgent issues, and we set the number of included hours individually based on your site. Since we don't use pre-built platforms, we can tailor maintenance and additional integrations without the technical constraints that come with third-party solutions. If you need development of more demanding functionality alongside support, check out our page on custom web applications. For a quote tailored to your site, get in touch through Moxy-web.
Frequently asked questions
What exactly does an SLA mean for website support?
An SLA is a contract defining the service level between you and your support provider, including response times, resolution targets, and availability. Formally, it's an agreement that serves as a benchmark for accountability whenever an outage or technical issue occurs.
What's the difference between response time and resolution time?
Response time tells you how quickly a provider contacts you after you report an issue; resolution time tells you when the issue is actually fixed. Both are typically defined separately in the contract for each priority level, from P1 to P4.
How does a priority matrix affect response targets?
A priority matrix classifies an incident by impact and urgency into classes from P1 to P4, each with its own response and resolution target. A model like this helps ensure the issues most affecting site performance get handled first.
Why is planned maintenance excluded from the availability calculation?
Planned maintenance is a window announced in advance, during which a provider carries out updates, so by agreement it doesn't count toward the site's availability calculation. The contract should also specify a minimum notice period, such as 48 hours in advance.
What should I check before signing an SLA with a support provider?
Check the support hours, exact response and resolution targets for each priority, the escalation process, and the conditions for pausing the resolution clock while waiting on you or a third party. At Moxy, we define these elements individually based on your site's scope; you can find more about our team on our about us page.