How to Set Up Uptime Monitoring for Client Websites

Start with the checks that actually matter for each client site#

Most agency monitoring fails for the same reason: you turn on everything at once and drown. Setting it up properly is a selection exercise, not a configuration sprint.

Every client site has a small number of things that must stay true. Your job is to name them, then watch only those. Start with the checks below and assign each one a clear owner and a clear answer to "what breaks if this fails?"

HTTP checks confirm the page loads and returns a healthy status code. Watch the homepage plus two or three pages that represent real money: a pricing page, a checkout, a login. Watching every URL adds noise, not coverage.

API checks cover anything the site depends on for data. A contact form that posts to an endpoint, a search box, a booking widget. If the endpoint is down, the page still looks fine and the visitor still leaves.

TCP and ping checks tell you whether the server itself is reachable. They are the difference between "the app is broken" and "the network path is broken," which is the first question you will be asked.

Cron and heartbeat checks matter more than most teams expect. If a nightly sync or a backup job silently stops running, nothing looks broken until weeks later. A heartbeat check expects a signal on a schedule and pages you when it does not arrive.

SSL and domain expiry are the quietest failures of all. Certificates and domains expire on a fixed date, so put a check on each one and set the warning window at 30 days. It is the cheapest outage you will ever prevent.

Watch from more than one place#

A single monitor cannot tell the difference between a real outage and its own bad day. If the check runs from one region and the host has a routing blip in that region, you get a false alarm.

Run each check from at least three regions. A failure that appears in only one region is usually a network path issue, not a down site. A failure that appears in all three is real. This one decision does more to cut false alarms than any alerting rule you will write later.

Group checks by client before you route a single alert#

Once the checks exist, organize them by client. One group per website keeps three things simple: who gets paged, what gets reported, and what you can hand over when a contract ends.

Name groups the way your clients think, not the way your infrastructure is built. "Riverside Dental - website" reads better than "prod-eu-01-web". The naming matters because humans read it at 2am.

Inside each group, separate two kinds of checks:

• Customer-facing checks that page someone immediately when they fail.
• Housekeeping checks, like expiry windows, that go to a weekly digest.

Mixing them is how a certificate warning ends up waking you on a Saturday.

Route alerts so only verified failures wake someone up#

This is where alert fatigue is won or lost. A few rules carry most of the weight.

Verify before you alert. When a check fails from one region, re-run it from the other regions before sending anything. If the second and third regions return healthy results, the site is up and no human needs to know. Only confirmed failures across regions should reach a phone.

Send to one place, not five. Pick a single channel per client group. Split notification across email, chat and SMS and people stop trusting all three.

Set escalation in plain terms. If a customer-facing check is down and unacknowledged for 10 minutes, notify the on-call engineer. At 20 minutes, notify the account lead. Write these thresholds down and keep them short. Three steps is plenty.

Separate warning from critical. A response time rising from 400ms to 800ms is worth a note. A page returning a 500 is worth a call. Use different severity levels so the two never share the same channel.

Quiet the known windows. Scheduled deploys, backup jobs and maintenance should be muted in advance. A muted window is not a gap in coverage; it is a decision you made on purpose.

Connect slow to what you shipped#

Uptime is only half the story. A site that stays up but gets slower loses customers just as quietly.

Track response time and page weight over time, then line them up against your deploy times. When a release pushes response time up by 300ms or page weight up by 200KB, you will see it on the same chart. That is correlation, not proof, but it points you at the right commit. Without the two side by side, you are guessing.

Set reporting and escalation cadences your clients can read#

Your clients do not want a dashboard. They want to know their site was up, how fast it was, and what you did about the one time it was not.

Send a plain-language monthly report per client. Three numbers do most of the work: uptime percentage, average response time, and the count of incidents with a one-line cause for each. Skip the raw graphs unless someone asks.

Set the escalation wording now, while it is calm:

• Response time up, site up: note it in the monthly report.
• Verified outage under 5 minutes: fix it, mention it in the monthly report.
• Verified outage over 5 minutes: notify the client the same day, then include it in the report.
• Two verified outages in a month: review the checks and the host with the client.

For clients who want visibility without a login, a white-label status page covers it. They see current state in plain language, you keep the technical detail.

Put the setup on a schedule#

Getting this right once is easy. Keeping it right as clients come and go is the work.

Add a short review to each onboarding and each offboarding. New client: add their checks, name the group, set the thresholds. Departing client: confirm the checks are removed and the reports stop. Run a quarterly pass over every group to retire checks nobody reads and add the two or three checks that keep mattering.

Fifteen minutes per client, four times a year. That pacing keeps the alerts trustworthy, which is the only thing that makes monitoring worth having.

The short version#

Pick the checks each site truly needs. Watch them from three regions. Group by client. Verify failures before you wake anyone. Send alerts to one place with three escalation steps. Report to clients in plain language, on a fixed cadence. Then review the whole set every quarter.

Do that, and monitoring becomes what it should have been from the start: a quiet system that tells you what changed, and nothing more.