Watched from the outside, confirmed before you are told.

Getting a site in

1. Paste the URL and say which client it belongs to. Clients are how reports are grouped, so this matters later.
2. Prove the site is yours to monitor. One DNS record, one file, or one meta tag — whichever your access allows.
3. Choose where alerts go. Email, Slack, or both, set once for the whole agency.

Nothing is installed on your client’s site. No plugin, no agent, no server access, no FTP password. If a visitor can see it, we can check it; if they cannot, neither can we, and we will not pretend otherwise.

The four checks

Each runs on its own schedule against each site. They are separate on purpose: a certificate can be fine while the page is blank, and a page can load while looking wrong.

Is it up

We request the page the way a browser would and record the status code, the time it took, and what came back. Slow is not down, and the two are reported differently — a site that took nine seconds is a different conversation from a site that refused the connection.

Certificate

We read the certificate actually being served, check it is valid for the name it is serving, and count the days until it expires. Expiry is the failure that is entirely predictable and still happens constantly, usually on a weekend.

Does the page draw

A real browser loads the page and we look at what it produced. This is the check that catches the failure a status code cannot: a server that cheerfully returns 200 OK along with a blank white screen, because a plugin fatal-errored after the headers were sent.

Appearance

We take a picture and compare it with one you approved. A theme update that pushes the header off the page breaks nothing a machine would normally notice — no error, no failed request, just a site that now looks broken to every visitor.

The appearance check learns which parts of a page move on their own — a carousel, a cookie bar, a date — and stops counting them. A change also has to settle across more than one run before it is treated as real. Both exist for the same reason as everything on this page: a check that cries wolf is a check that gets switched off.

How a failure becomes an alert

It has to happen twice. A single failed run never alerts anyone, ever. We see a failure, we wait, and we look again. Only when a second attempt fails the same way does an incident open and a message go out.

The wait scales with how often that site is checked. A site checked every minute gets a short second look; a site checked every fifteen minutes gets a proportionally longer one. A fixed gap would either alert too eagerly on a slow schedule or take far too long on a fast one.

The cost of that rule is honest and worth stating: a failure that lasts less time than the gap between two checks is one we may never see. We would rather miss a thirty-second blip than wake you for one.

When the site recovers, the incident closes on the same evidence standard, and you are told that too. An alert that never gets a second message is an alert that leaves you checking by hand.

When the problem is ours

Our worker can time out. Our DNS can fail. The browser we drive can crash. None of those mean your client’s site is down, and none of them are ever reported as though they were.

A check we could not carry out is recorded as our failure, shown in its own state, and described in words — “could not be run from our side. That is our problem, not the site’s.” It is excluded from the counts in your client’s monthly report, and the report says how many were excluded rather than quietly dropping them.

This is the single most important thing on this page. Every monitoring tool that has ever been cancelled was cancelled because it blamed the customer for the tool’s own bad night.

Why we insist on verifying ownership

Before the first check runs, you prove you have control of the site, by one of three routes:

• a DNS TXT record at _plumbline.<domain> containing a token we issue;
• a file we name at /.well-known/;
• a meta tag on the homepage.

Verification is re-checked periodically. A site that stops verifying is paused after thirty days and you are told — not silently dropped, because a site you believe is being watched and is not is the worst state this product can be in.

Agencies sometimes read this as friction. It is the opposite: fetching a website repeatedly without a relationship is, at volume, indistinguishable from an attack. Verification is the line between a monitoring service and a stress-testing service, and it protects you as much as it protects the site.

What we keep, and why

Every check stores what we asked for and what came back. When an alert says a site was failing, you can open it and see the evidence, rather than taking our word for it. “Check failed” is not a product.

• Check results are kept for thirteen months, so a monthly report always has a year to compare against.
• Screenshots are kept for ninety days, unless they are attached to an open incident or are an approved baseline.
• Delete a client and everything belonging to them is purged within thirty days.

The details, including what this means for personal data that a screenshot might incidentally capture, are on the privacy page.

The monthly report

On the first of each month, each client gets a report in your branding: what we checked, how many times, what we caught, when it was fixed. It is emailed on your behalf, or you can read it first and send it yourself. What you see is exactly what they receive.

It does not contain an uptime percentage, and it never will. Here is why.

Ask for an invitation See pricing