Web Agency SLAs: What to Promise Clients (and What Not To)

Sooner or later a client will ask, "So what SLA do you offer?" The most common reaction, which is to search online for a template and adapt it, is also the one that does the most damage. The templates you find are written for hosting providers and enterprise vendors, and they contain promises a small agency can't keep.

Here we look at what an agency of three, five or ten people can really promise, and how to write it so it holds up when a real incident arrives.

What an SLA is, in two lines

A Service Level Agreement is the part of the contract that states the promised level of service in measurable terms, and what happens if it isn't met. It isn't a vague promise of quality ("prompt support"): it's a set of numbers and times that, at the end of the month, were either met or not. If a line can't be checked against data, it isn't an SLA, it's a reassurance, and the two need to be kept apart, because the client reads them as the same thing.

Why you shouldn't copy an enterprise hosting SLA

The template you find online almost always promises an uptime percentage. It's worth translating those percentages into real minutes, over a 30-day month, which is 43,200 minutes:

Look at the last row. Promising 99.99% means committing to keep a client's site unreachable for less than five minutes a month: a single restart of the hosting server, a scheduled maintenance window that runs a little long, a certificate renewal that goes wrong, and the month is blown.

And this is the point that makes the whole exercise senseless for an agency: that number doesn't depend on you. A site's uptime depends on the hosting, which in most cases is chosen and paid for by the client, and over which you have neither control nor visibility. You'd be promising the behavior of someone else's infrastructure.

A small client, for that matter, doesn't really expect 99.99%. They expect not to be the last to know their site is down. That's a completely different thing, and it's something you can promise in good faith.

What to promise instead of a percentage: three times

Instead of a number you don't control, commit to three that you control entirely.

1. Detection time. How soon you notice the site is down. This is the most important of the three commitments, because it's the only one that covers the period when the client doesn't yet know anything.

2. First-response time. How soon the client receives a message from you saying something has happened and you're working on it. First response, not resolution: it depends only on you, which is why you can always meet it.

3. Response (start-of-work) time. How soon you actually start working on it, with the coverage hours stated alongside. A response time without a time window is ambiguous, and ambiguity in an SLA always works against whoever wrote it.

Keep the three times separate even when they're close together, because they fail for different reasons: detection fails if nobody was looking, first response fails if you're in a meeting, and response fails if the problem belongs to someone else.

Detection is the easiest promise to keep, but only with a tool

Of the three promises, detection is the hardest to keep by hand and the easiest to keep with a tool.

By hand, "we notice an outage within 15 minutes" requires someone to open that site every quarter of an hour, for every client, Saturdays included. No agency does that, and promising it in writing means putting something false in a contract. With automated monitoring, the same sentence becomes the most trivial promise in the package: the check happens regardless, whether it's the middle of the night or Ferragosto (Italy's mid-August holiday).

The number you write down is derived, not invented:

declared detection time
  = check interval + confirmation time + margin

With checks every 5 minutes and a confirmation from a second location that takes a few seconds, actual detection is typically under 6-7 minutes. The number to put in the contract isn't that one: it's that one plus the margin, which is 15 minutes. In an SLA you always state the reasonable worst case, never the average case. A commitment you meet every month is worth more than an ambitious one you meet almost every month.

An SLA paragraph you can write and that is true

A complete example, for an agency of 3-5 people with no overnight on-call. Adapt it, don't copy it word for word:

Service Levels: Monitoring and Support

Coverage: Monday to Friday, 9 a.m. to 7 p.m., excluding public holidays.

Detection: the site is checked automatically 24 hours a day from several independent locations. A confirmed outage is detected within 15 minutes of its start, at any time, including outside coverage hours.

First response: during coverage hours, the Client receives a communication within 60 minutes of detection, with what is known at that point and the time of the next update. Outside coverage hours, within 60 minutes of the start of the first available coverage window.

Response: diagnostic work begins within 2 business hours of detection. Resolution times depend on the nature of the problem and are not subject to commitment when the cause is external (hosting, registrar, DNS provider, third-party services).

Measurement: the times can be verified against the incident history, which records the start and end of every outage and can be viewed by the Client at any time on the public status page; an exportable version is also provided on request.

Exclusions: scheduled maintenance announced at least 48 hours in advance; outages caused by changes made by the Client or by third parties not engaged by the Agency; hosting or DNS provider outages, for which the Agency commits to detection, communication and ticket handling, not to direct resolution.

If targets are missed: if the first-response or response times are not met, the Client is entitled to a discount equal to [10]% of the monthly fee for the month concerned.

Four things set it apart from a downloaded template. It promises only times that depend on the agency. It states the coverage hours instead of letting them be assumed. It says where to look at the data to verify it. And it ends with a small but real consequence instead of a frightening, theoretical penalty. On that last point: a limited, defined discount on the fee is sustainable, and precisely because it's credible, it reads as seriousness. Compensation proportional to the client's lost revenue isn't sustainable for any small agency, and promising it on a site that generates orders is a risk out of all proportion to the fee you're collecting.

The mistakes you pay for

Promising uptime percentages. It's the most common one: it depends on the hosting, not on you. If the client wants it in writing, the honest wording is "the site's uptime depends on the hosting infrastructure; the Agency detects and documents its outages."

Writing 24/7 if you're not 24/7. A client who finds out at two in the morning that "continuous support" meant "we'll call you back tomorrow" loses trust faster than one you never promised anything to overnight. Note, though, that detection and coverage can have different hours: the example above promises 24/7 detection and 9-to-7 response, which is an honest, sustainable combination.

Not defining what counts as "down". Site unreachable, site slow, a single page throwing an error, checkout broken but home page working: these are different situations. If the contract doesn't say, the client will decide, at the worst possible moment to argue about it.

Not saying who measures. Without a stated data source, every discussion about a time becomes your word against theirs.

An SLA is only as good as the data that proves it

The two hardest lines in the whole example paragraph are the one on detection and the one on measurement, and they're hard for the same reason: they require a system that checks the sites when nobody is in the office, and that keeps a record of what it saw.

That's what Statuo does: continuous checks from several independent locations, with an outage declared only when at least two locations confirm it, so the alert you pass on to the client is a fact, not a suspicion. Every confirmed outage opens an incident with a start and end time, which goes into the history and onto the public status page under your agency's brand (90 days of daily uptime, recent outages with their duration); the data can be exported as CSV or JSON if you need to attach it to a year-end review.

It's the difference between an SLA the client has to take on trust and one they can check for themselves, which is the only kind worth writing. The free trial lasts 14 days, with no credit card: enough to turn on monitoring for the sites you look after and set the three times in your SLA by watching what really happens, instead of estimating them.

The rest of the contract (updates, backups, security, and how to split them into line items the client can evaluate) is the subject of the article on what to include in a maintenance contract: the SLA is one of four families, not the whole contract.