The client's call is the agency's monitoring system — until the call comes at 11pm about a site that went down at 4. Here is how agencies watch what they ship without hiring for it.
An agency monitors client sites well when every site it has shipped is registered under its client, checked from the outside every few minutes for availability, response time, HTTP status and certificate expiry, assigned to a named owner who is alerted once, and summarised monthly in a report the client receives. That structure — per client, with an owner, with a report — is what turns monitoring from a cost the agency absorbs into a maintenance service the client pays for. None of it needs an operations hire; it needs the sites in one place and the alerts going to the right person.
An agency ships a site, invoices, and moves on. Six months later the certificate expires, a plugin update breaks checkout, or the hosting provider has a bad hour — and the first the agency hears is the client's message, often with a screenshot, often at night. The site was down for four hours; the agency's reputation was down for four hours; and the agency has no record of when it started, which makes the conversation worse. Multiply by every site ever shipped. Why the user's report is always late.
Agencies already organise work per client — projects, hours, quotes, invoices. Monitoring should sit in the same structure: each client has its assets (the marketing site, the web app, the API, the staging environment if it matters), each asset has an owner on the agency side, and each asset carries the client's SLA tier. That gives you three things immediately: a per-client view when the client calls, a per-owner view for the person on the hook, and a per-client report at month-end. The same hierarchy that makes reporting work for billable hours makes it work for uptime.
| Availability | Outside-in HTTP check every few minutes; alert on confirmed failure, not one blip |
|---|---|
| Response time | Latency against the site's own baseline — a WordPress site that is normally 600 ms and is now 3 s is degraded even though it is up |
| HTTP status | A 200 that became a 500, a redirect loop, a 404 on the home page after a migration |
| Certificate expiry | Daily check; alert at 14, 7 and 3 days. Why this now matters more |
| Frontend errors | JavaScript errors from real visitors — the broken form that returns 200. The failures uptime checks cannot see |
| Deploys | When the last change shipped, on the same timeline as incidents. Did the deploy break it? |
That is the full checklist for a marketing site or a small web app. APIs and larger apps add more — see the SaaS monitoring checklist — but the six above catch the calls agencies actually get.
The failure mode for agencies is volume: twenty sites, each raising an alert per signal, all to one Slack channel that everyone mutes within a week. The rules that prevent it: one incident per asset, not one per symptom; auto-assigned to the asset's owner, so it is one person's problem; alerted once by email or Slack, not every five minutes until acknowledged; quiet hours so a non-critical marketing site's 2am blip waits for morning; and auto-close on recovery so the channel is not full of things that fixed themselves. Alert fatigue in small teams goes deeper.
Clients will pay for monitoring when they can see it. Two artefacts do that. A monthly SLA report per client — uptime percentage against the tier they are on, incidents with detection and resolution times, response-time trend, certificate status, deploys — sent whether or not anything happened; a quiet month is the service working. And a client-facing status page, private to that client via a token URL, that they can check before they call. Both are built from the monitoring data you already collect. How to produce the report · When a status page earns its keep.
Then price it: a maintenance retainer that includes monitoring, the report, the status page, and a stated response time for incidents. Agencies that do this find the retainer often outlasts the project it followed. Sizing the retainer.
| Structure | Assets grouped per client, each with an owner and an SLA tier |
|---|---|
| Six checks | Availability · response time vs baseline · HTTP status · certificate expiry · frontend errors · deploys |
| Alert rules | One incident per asset, auto-assigned, alerted once, quiet hours, auto-close on recovery |
| Monthly artefact | Per-client SLA report: uptime vs tier, incidents, MTTD/MTTR, latency, certificate, deploys |
| Client-facing | Private status page per client via token URL |
| Commercial | Bundle into a maintenance retainer with a stated response time |
By registering every shipped site under its client, checking each from the outside every few minutes for availability, response time, HTTP status and certificate expiry, collecting frontend errors from real visitors, assigning each site to a named owner who is alerted once on a confirmed failure, and sending each client a monthly SLA report. The per-client structure is what makes it manageable across dozens of sites.
Availability, response time against the site's own normal, HTTP status, SSL certificate expiry, JavaScript errors from visitors, and when the last deploy happened. Those six cover the incidents clients actually call about on marketing sites and small web apps; APIs and larger applications need more.
One incident per asset rather than one alert per symptom; automatic assignment to the asset's owner; a single alert by email or Slack rather than repeated pages; quiet hours for non-critical sites; and automatic closure when the site recovers. Without those rules, a shared alerts channel is muted within a week.
Yes, and most should. Bundle monitoring with a monthly SLA report, a private status page and a stated incident response time into a maintenance retainer. Clients pay for what they can see, and the monthly report makes a quiet month visible as a delivered service.
Not necessarily. What clients need to see is a report with their name on it and a status page they can check; whether the underlying tool is branded matters less than whether the per-client report and page exist. Prioritise per-client structure and reporting over branding.
A declared availability target — typically 99%, 99.5% or 99.9% — against which the site's measured uptime is reported each month. A marketing site might be on 99%; a client's checkout on 99.9%. The tier sets the error budget the monthly report is measured against.
Merik's Digital Operations module is organised the way agencies already are: assets belong to clients. Register each client's website, web app or API, and Merik checks it from the outside every few minutes — availability, response time, HTTP status, daily SSL expiry — learns its normal over 14 days, and raises at most one early warning per asset when it drifts. Confirmed failures open an incident auto-assigned to the asset's owner, alerted once by email or Slack with quiet-hours rules. A one-line browser snippet reports JavaScript errors from real visitors; GitHub and Vercel webhooks put deploys on the incident timeline.
Monthly per-client SLA reports and private token-URL status pages are built in, measured against the SLA tier you declare per asset — so the retainer has something to show every month. It sits in the same workspace as your clients, projects, task log, quotes and invoices. See the Digital Operations module.
Tiers and their minutes, the seven sections, and how to present a quiet month.
When it earns its place, what to show, private per-client pages, and the honesty rules.
The complete checklist — uptime, APIs, frontend errors, certificates, dependencies, deploys.