What a Real Website SLA Looks Like (P1–P4, Explained)
If a provider tells you they offer “great support,” ask them one question: what’s your SLA? A service-level agreement turns a vague promise into specific, measurable commitments — how fast they’ll respond, and how fast they’ll fix things, graded by how serious the problem is. This explains what a real website SLA looks like, using the P1–P4 model and actual response times.
It’s part of our wider series on keeping a site reliable after launch; the bigger picture sits in the post-launch decay pillar.
In this article:
What a website SLA is
A website SLA (service-level agreement) is a documented commitment that defines how quickly your provider will acknowledge and resolve issues, usually graded by severity from P1 (critical) down to P4 (minor).
It exists to replace “we’ll get to it” with something you can actually hold a provider to. A good SLA tells you two things for every kind of problem: how soon a person will confirm they’re on it (acknowledgement), and how soon you can expect it fixed or worked around (resolution). Without one, “support” is just goodwill — fine until the day your site goes down and you’ve no idea when it will be back.
Why severity levels exist
Severity levels exist because not every website problem is an emergency — a site being completely down needs a very different response from a slightly misaligned button, and an SLA should treat them differently.
If everything is “urgent,” nothing is. Grading by severity lets a provider put the right resources on the right problem quickly: drop everything for an outage, schedule a cosmetic tweak. It also sets honest expectations on both sides — you know a critical issue gets a rapid response, and you’re not paying for someone to treat a typo with the same urgency as a payment failure. That’s the job the P1–P4 scale does.
P1 to P4, with real examples
The P1–P4 model grades issues from P1 (critical — the site is down or insecure) to P4 (low — a minor cosmetic fault), with faster acknowledgement and resolution targets at the more serious end.
| Priority | What it means (example) | Acknowledged within | Resolution target |
|---|---|---|---|
| P1 — Critical | Site down, payments failing, or a security breach — major loss of revenue or reputation | 2 hours | Workaround or fix within 4 hours |
| P2 — High | Key functionality broken for many users — e.g. search down, or you can’t update the CMS | 4 hours | Within 1 business day |
| P3 — Medium | A fault with a workaround available — e.g. an integration failing occasionally | 24 hours | Within 2 business days |
| P4 — Low | Minor cosmetic or interface issue that doesn’t stop anyone using the site | 48 hours | Within 10 business days |
These are targets graded by urgency: a P1 is measured in hours, while a lower-priority P4 carries a couple of working weeks as a scheduled fix. The point isn’t that everything is instant — it’s that you know, in advance, exactly what to expect for each kind of problem.
Acknowledgement vs resolution
Acknowledgement and resolution are two different promises: acknowledgement is how fast a person confirms they’ve seen the problem and started work; resolution is how fast it’s actually fixed — and a credible SLA commits to both.
A lot of “support” promises blur these together. “We’ll respond within 24 hours” often means an automated reply, not a human, and says nothing about when the thing is fixed. A real SLA separates them: for a P1, you’re acknowledged within two hours — a real person, on it — and you have a workaround or fix targeted within four. Knowing both numbers is what lets you actually plan around a problem rather than just wait and hope.
The honest bit: most providers don’t offer one
The uncomfortable truth is that most agencies and freelancers don’t offer a website SLA at all — support is best-efforts, dependent on whether the person is free, on holiday, or busy with a bigger client.
It’s not usually bad faith. A single freelancer or a small studio genuinely can’t commit to response times around the clock. But it means that when your site breaks, you’re in a queue you can’t see, with no committed timeline. For a firm whose website is a real source of clients — or one in finance or legal, where downtime carries regulatory and reputational weight — “I’ll get to it when I can” isn’t good enough. The presence of a written SLA is one of the clearest signals that a provider’s support is a system, not a favour.
What Agile One commits to
Agile One commits to the P1–P4 standard above as part of the subscription — published acknowledgement and resolution targets, backed by 24/7 monitoring, daily backups, and a safe deployment process for every fix.
With Agile One — our premium web subscription — that SLA is included in the fee, not sold as an upsell. Issues are graded P1 to P4 and handled to the targets above, with email, ticketing and chat support behind them. And fixes aren’t applied straight onto your live site — they go through our tested deployment pipeline, so the cure can’t cause a new problem.
We’re deliberately careful about what we promise. We don’t claim your site will never go down, or that every fix is instant — no honest provider can. What we commit to is a standard: rapid acknowledgement, defined resolution targets, constant monitoring that often catches issues before you even notice them, and daily backups so there’s always a way back.
It’s all part of the same managed service — included in the £500 a month, with no lock-in — alongside everything else the subscription covers.
FAQ
Tired of support that’s a favour rather than a commitment? See what’s included →
Related
Articles
