Uptime monitoring for agency client sites

Uptime monitoring for an agency means a service loads every client's site on a schedule and tells you when one stops answering, before the client notices. Monitor three things per site: the home page answering, the SSL certificate's end date, and the domain's renewal date. Those three catch most of the outages small business sites have.

This guide covers what to check, how intervals and retries decide how fast and how noisy alerts are, the expiry dates that cause the most avoidable outages, and how to show uptime to clients.

What to check on each site#

Start with the first three for every client. Add a key page for clients whose revenue depends on one.

What counts as down#

A monitor sends a request and judges the answer. The rules matter more than they look:

• Server errors (500 and up) are down. The server is reachable but failing.
• No answer within a time limit is down. Ten to 30 seconds is common. A site that takes 20 seconds to answer is down for its visitors anyway.
• A home page that returns "not found" (404) is down. It usually means a broken deploy or a moved site.
• "Forbidden" or "too many requests" (403, 429) usually means up. Bot shields such as firewalls answer monitors with these. The server is alive.

Interval, retries and false alarms#

Every alert setup trades speed against noise. Two settings decide it:

• Interval: how often the site is checked.
• Confirmations: how many failed checks in a row before you are told.

The worst-case time to know is roughly interval times confirmations:

Retrying a failed request a few seconds later, before calling the check failed, removes most remaining blips.

For brochure sites and small stores, 30 minutes to know is fine; the client rarely loses more in that time than a night's sleep is worth. Google's SRE book puts the principle plainly: every page should be actionable, and alerts that fire too often get skimmed or ignored (Google SRE). A monitor that cries wolf is worse than none, because the real outage arrives in a muted channel.

Uptime percentages, in minutes#

Clients and contracts speak in percentages. Translate them, for a 30-day month (43,200 minutes):

A monitor that checks every 15 minutes cannot prove 99.99 percent; one missed check is already more than the month's allowance. Do not promise a figure your monitoring cannot measure.

SSL certificates#

A lapsed certificate takes a site down as surely as a dead server: browsers show a full-page warning and most visitors leave.

Certificates now renew automatically on most hosts, so the failure to watch for is renewal that stopped working. Lifetimes are getting shorter, which makes that more likely to bite. The CA/Browser Forum voted to cut the maximum public TLS certificate lifetime from 398 days to 47 days, in steps from March 2026 to March 2029 (CA/Browser Forum), and Let's Encrypt is moving its default certificates to 64 days in 2027 and 45 days in 2028 (Let's Encrypt).

Auto-renewal usually runs about a month before the end date. A certificate within two weeks of its end is a strong sign renewal has failed. Public Certificate Transparency logs, searchable at crt.sh, show every certificate issued for a domain, so a monitor can read the end date without connecting to the site.

Domains#

An expired domain takes down the site and the email together. Registrars must send at least two reminders before expiry, about a month and about a week ahead (ICANN). Those go to whoever registered the domain, often a client's former employee or a developer long gone.

Watch the end date yourself. The registry publishes it in its RDAP record, the standard JSON replacement for WHOIS (RFC 9083); a few country registries do not publish it. Warn the client 30 days out, and get the domain onto a card that will not expire.

Reporting uptime to clients#

• Put uptime in the monthly report, as one line: "Your site was up 99.97 percent of October; one 25-minute outage on the 14th, caused by the host." (Example numbers.) It shows work clients otherwise never see. The client reporting guide covers where it goes.
• Tell them about outages yourself, before they hear it from a customer, with the cause and what changed.
• Route alerts to where your team works, a shared Slack or Teams channel, not one person's inbox.

Where Sporetag fits#

From Sporetag's uptime code and help, on paid plans: each site's home page is loaded every 15 minutes with a 15-second limit and retried twice before a check fails; a site is down after two failed checks in a row. 401, 403 and 429 count as up; 404, 410 and 500 and up count as down. SSL end dates come from Certificate Transparency logs and domain dates from RDAP, once a day, with warnings at 14 and 30 days. Alerts go by email, and to Slack or Teams if you choose, at most once a day per kind per site. The Overview lists every client site with the ones that need you first, and reports can carry an Uptime block.

Common questions#

How often should I check client websites for uptime?

Every 5 to 15 minutes, with two failed checks in a row before an alert, suits most small business sites. Check more often only where a few minutes of downtime costs real money.

What uptime should an agency promise clients?

Only what the host's own service level agreement covers and your monitoring can measure. Read the host's figure first; 99.9 percent allows about 43 minutes of downtime a month.

Why monitor SSL expiry if certificates renew automatically?

Because automatic renewal fails silently: a changed DNS record, a moved host or a full disk stops it. A certificate close to its end date is the earliest sign.

What happens if a client's domain expires?

The website and email stop working. The owner can usually still renew for a short time after expiry, but the name can be lost for good if it is deleted and not restored.

Sources#

• Google SRE book: Monitoring distributed systems. Checked October 2026.
• CA/Browser Forum: Ballot SC081v3, reducing validity periods. Checked October 2026.
• Let's Encrypt: Decreasing certificate lifetimes to 45 days. Checked October 2026.
• ICANN: Expired Registration Recovery Policy. Checked October 2026.
• IETF: RFC 9083, JSON responses for RDAP. Checked October 2026.
• Figures marked as examples are made up for illustration.