Why the client learns about the outage before the agency
Without monitoring, an outage is discovered from the wrong end: the client opens the site, sees an error and writes to you. The delay between the outage and your reaction is no longer measured by you, it is measured by them. Conversely, a badly tuned setup fails in another way: ten alerts a week of which nine are false, a channel nobody reads any more, and the real outage lost in the noise.
The goal is therefore not to watch everything, but to know three things for each site: is it reachable, does it answer with the right content, and are its deadlines (certificate, domain) still far away. A second need appears at month end: the client asks for proof of availability, and only a continuous, timestamped measurement lets you answer without reconstructing the story from memory.
Probe types and what each one detects
Scroll the table
| Probe | What it detects | What it does not see |
|---|---|---|
| HTTP (response code) | Stopped server, 5xx error, timeout, unreachable site | An error page returned with a 200 code |
| HTTP with expected keyword | Blank page, application error message, missing database, forgotten maintenance page | A visual defect or a broken feature further along the journey |
| TLS certificate | Expired or soon-to-expire certificate, incomplete chain, wrong host name | An offline site whose certificate is still valid |
| DNS | A, AAAA or MX record changed or gone, zone no longer answering | A web server down behind correct DNS |
| Domain expiry | Domain close to its due date, automatic renewal not active | The health of the server |
| Scheduled-task heartbeat | Backup, cron job or message queue that did not run within the expected delay | A task that runs but produces a wrong result |
The confirmation rule: n checks before alerting
Most false positives are outages lasting a few seconds: a service restart, a network cut on the probe side, a load spike. An alert fired on the first error wakes someone up for nothing. The remedy is a single rule: declare the outage only after n consecutive failed checks, spaced by a short interval.
The cost of this rule is known and can be computed: detection delay is roughly the interval multiplied by n. With one check per minute and three consecutive failures, you alert after about three minutes. For a brochure site that delay is acceptable. For a shop during a sale, shorten the interval rather than removing the confirmation. And once an incident is declared, keep checking: the end of the incident is also confirmed by several successes in a row, otherwise a flapping site produces a burst of alternating messages.
Causes of false positives to remove
- Single probe — one probe in one network confuses its own outage with the site's; two independent locations, or a second check from another point, settle it.
- Timeout too short — a response timeout set below the warm-up time of a cold WordPress site triggers an alert on the first visit after a quiet period.
- Status code only — a check limited to a 200 code misses the blank page, while a fragile keyword (a tagline that changes) alerts at every editorial change; pick a stable element, such as the brand name in the footer.
- Redirects not followed — a redirect from http to https or from the apex to www, badly handled by the probe, looks like an error.
- Bot protection — a web application firewall or rate limit that blocks the probe address produces regular 403 responses; allow the probe address rather than lowering the site's protection.
- Undeclared maintenance — a scheduled update that cuts the service for a few minutes triggers an alert and dirties the month's report; declare it beforehand, see below.
Indicative starting thresholds, to adjust per site
Scroll the table
| Setting | Indicative starting value | Reason |
|---|---|---|
| Check interval | 1 minute for a critical site, 5 minutes for a brochure site | The shorter the interval, the faster the detection, but the higher the load on the probe |
| Failures before alert | 3 consecutive checks | Filters cuts of a few seconds without delaying detection by more than a few minutes |
| Maximum response time | 10 to 30 seconds depending on the site | Beyond that the visitor has already left the page |
| Successes before incident ends | 2 consecutive checks | Avoids bursts of opening and closing messages on an unstable site |
| Certificate expiry alert | 30, 14 then 7 days before the deadline | Leaves time to understand why automatic renewal failed |
| Domain expiry alert | 60 then 30 days before the deadline | An expired domain costs more to recover than a server outage |
Setting up monitoring for a portfolio
Build the site inventory
List each site with its address, its host, its domain due date and a contact on the client side. Without this inventory, you cannot say which site is not monitored.
Choose a stable keyword per site
Open the home page and pick a text present in every normal response, for example the brand name. Check it by hand with
curl -s https://your-domain.com | grep -c "Brand name".Measure a site's response by hand
Before configuring the probe, read the code and response time with
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://your-domain.com. This reference time is used to set the maximum delay.Check the certificate
Read the end-of-validity date with
echo | openssl s_client -connect your-domain.com:443 -servername your-domain.com 2>/dev/null | openssl x509 -noout -enddate, then enable the certificate probe with the thresholds from the table.Check the DNS
Note the expected values with
dig +short A your-domain.comanddig +short MX your-domain.com, then have the DNS probe alert on any difference.Tune interval and confirmation
Apply the starting values from the table, then let it run for a week. A false alert is fixed by addressing its cause, never by disabling the probe.
Connect each probe to a channel
Link critical alerts to a channel that wakes someone up, and warnings to a channel read during the day, as detailed below.
Maintenance windows and alert channels
A maintenance window is a time slot declared in advance during which a site's outages do not trigger an alert. It does two things: it spares your on-call person, and it stays visible in the report, where the period is counted separately instead of being hidden. A well-kept window states the site, the start time, the end time and the reason. Do not extend it out of habit: a window that is permanently open is monitoring that is switched off.
For channels, separate the urgent from the informative. A confirmed outage of a production site goes to a channel that rings, for example a team messaging app with mobile notification or an on-call call. A certificate 14 days from expiry goes to a channel read every morning, such as a shared mailbox or a dedicated thread. Also plan a second recipient: an alert read by only one person fails on the day they are on leave.
Break the probe before trusting it
A probe that has never alerted is not proven. On a test site, deliberately change the expected keyword or stop the web service, then check three things: the delay before the alert matches the interval times n calculation, the message arrives on the right channel, and the closure fires when the service returns. Replay this test after every change of probe or channel.
The monthly report: what the client reads in two minutes
The client does not read an event log. They want to know, on one page, whether their site held up, what happened when it did not, and what you changed since. A useful report fits on one page and is generated from the same measurements that trigger your alerts, with no manual editing: an edited report loses its value as evidence.
The calculation of measured availability is deliberately simple: the minutes during which the site answered, divided by the minutes of the period, after removing declared maintenance windows. As an illustration only, 22 minutes of downtime over a period of 43,200 minutes is about 0.05% of time lost. This is a worked example, not a commitment: always state the method next to the result, and never promise a figure in advance.
Monthly report template
Scroll the table
| Section | Content | Example |
|---|---|---|
| Period and scope | Start and end dates, site, active probes, check interval | From the 1st to the 30th of the month, home page and contact page, check every 5 minutes |
| Measured availability | Calculated percentage, minutes of downtime, calculation method | 22 minutes out of 43,200, declared maintenance excluded |
| Timestamped incidents | Start, end and duration of each incident | On the 12th, from 02:14 to 02:36, which is 22 minutes |
| Cause | Established origin, or an explicit note that it remains unknown | Service restart after a security update |
| Actions taken | What was fixed or decided | Planned restart now scheduled outside opening hours |
| Maintenance windows | Declared slots, deducted from the calculation, with their reason | On the 20th, from 03:00 to 03:30, system update |
Availability measured by the agency and the host's SLA: two different things
The agency's report measures what a visitor sees: did the site answer, with the right content, from the outside. The host's SLA is a contractual commitment about the infrastructure, with its own definitions, exclusions and compensation terms. The two can diverge without anyone lying: an application that crashes while the server keeps running does not count against the host, but it does count against the site.
So never present your measurement as the host's guarantee, or the reverse. In the report, say what was measured, by which probe, from which point. If an incident comes from the infrastructure, attach the request made to the host and its answer, and read the terms of its commitment before promising any compensation to your client. This clear split of responsibilities also protects the relationship: you document, you do not promise in place of a third party.
When the portfolio grows
At five sites, a spreadsheet and a few probes are enough. At fifty, the difficulty becomes completeness: a forgotten site, a domain whose expiry nobody watches, an outdated client contact. Appoint an owner for the inventory, add probe creation to the go-live checklist of every new project, and cross-check the list of monitored sites against the list of contracts each month.
Availability probes answer the question "does the site work?". They complement, without replacing, server resource monitoring and the monthly security audit: a full disk, saturated memory or a late update are causes of outages that are better seen coming than discovered.
The official documentation
curl manual: https://curl.se/docs/manpage.html
openssl s_client command: https://docs.openssl.org/master/man1/openssl-s_client/
openssl x509 command: https://docs.openssl.org/master/man1/openssl-x509/
dig tool: https://bind9.readthedocs.io/en/latest/manpages.html
RDAP protocol and domain expiry dates: https://www.icann.org/rdap
Uptime Kuma documentation: https://github.com/louislam/uptime-kuma/wiki
