I have had a company website for years, and for most of them my knowledge of whether it worked rested on two sources: my own browser, and a phone call from somebody who happened to be looking for something on it. Both share the same flaw - they only work while somebody is looking. On top of that, checking a site by hand after every update is a fairly monotonous job, and it rarely catches everything. If you have no automated tests, or do not even know where to start with them, it is worth knowing that you can attach monitoring to a site that will handle part of this for you by itself, and keep working after you have gone to bed.

The reason I started thinking seriously about automated monitoring was an ordinary update. I updated the plugins, clicked through the home page, it looked fine, I went to bed. Three days later it turned out the contact form had not been sending mail and the site was loading twice as slowly as before. Nobody reported it to me.

So I set up monitoring, and configured it myself. Below is exactly what I have switched on and why, because it is not obvious at first glance: "the page opens" is the least useful piece of information in the whole set.

Availability, but with a history

I started with the simplest thing: an HTTP monitor on the home page, checked every minute. Plus separate monitors on the two subpages that matter to me - the offer page and the page with the contact form. Because a home page can be working while the rest of the site is not.

The interval is set per monitor, from one minute to twelve hours. The critical things I check every minute, the less important ones every five or fifteen. There is no point checking everything every minute just because you can.

The important part, though, is not that I get an alert. The important part is the history. I have an availability strip covering the last 90 days, a list of events with exact times and reasons, and an uptime percentage for the period. That is the thing that changes the conversation with your host: instead of "I have a feeling something happens at night", I show a list of outages with dates and durations. That is hard to argue with.

Alerts go out by e-mail, as browser push notifications, and to my phone through ntfy. I have all three, because each works in a different situation. The times in the e-mails are in my own time zone, so I do not have to convert UTC in my head at two in the morning.

There is one more screen I look at every morning: "Needs attention". If nothing is down and no certificate is expiring soon, it is empty. That is a surprisingly pleasant feeling.

Speed, the thing an outage alert will never catch

An outage is easy. The worse situation is the one where the site answers, only ever more slowly - after an update, after a plugin was added, after the host put more neighbours on the same server.

That is what the server response time measurement is for (TTFB, the time to first byte). It is measured every minute, not once in a while from a single click, and shown as a median and a P95, day by day. That gives me a baseline - I know what "normal" looks like for my site, and I can see on the chart the moment it changed.

When TTFB rises and stays there, it usually means one of three things: an overloaded server, slow database queries, or a cache that got switched off. I do not always know which straight away, but I know when it started - and that is usually enough to get to the cause.

Regressions after deployments and after SEO changes

For me this is the most important part, and the reason I set all this up in the first place.

Once a day the site goes through a health audit. Several dozen things are checked across five categories: availability, security, SEO, best practices and performance (the last one based on Core Web Vitals from real Chrome user measurements, that is Google's CrUX data). The result is compared with the previous audit.

Of the things that genuinely change my life after a deployment:

  • Indexing - whether a noindex slipped into the robots meta tag or the X-Robots-Tag header. This is the one mistake that can cut a site out of Google and leave no visible trace behind.
  • Title, meta description, canonical address, H1, the lang attribute - the things somebody can overwrite while changing a template.
  • Mixed content - resources loaded over HTTP on an HTTPS page. A classic after uploading images from an old address; it ends with the padlock disappearing.
  • Redirect chains - whether the site is now reached in two hops instead of one.
  • Security headers (HSTS, CSP, X-Frame-Options, cookie flags) - these do not usually vanish on their own, but they do vanish when a server configuration changes, and it is good to know about it straight away.

What matters most, though, is the form this reaches me in. The audit history is not a list of runs but a change log: an entry appears when something broke, got fixed or changed, plus one control entry a week so you can see we are still watching. So I am not digging through thirty identical reports a month - I see five dates on which something actually moved.

For every regression detected I get context from the same time window: whether the page content changed, whether any headers disappeared, whether the server changed, how much the HTML grew, whether a redirect appeared. That turns "something broke" into "it broke when you changed X".

The score for the page itself, without CrUX, is calculated separately. That makes sense: Core Web Vitals can move without any change on my side, so regression alerts are triggered only by the part of the score I genuinely influence.

Content monitoring, or catching "it works, but not really"

A server can answer with a 200 and display a database error message. To classic monitoring everything is fine; to a visitor it very much is not.

That is why I have content monitoring switched on for the offer page. You can enter up to five phrases here and pick one of two modes:

  • must contain - in my case a fragment of text from a section that renders dynamically. If it disappears, something failed to load.
  • must not contain - "Error establishing a database connection", "Fatal error", "Warning:". After a failed PHP or plugin update, that is exactly what turns up on the page.

It costs me one minute of setup and it has already caught two situations I would not have noticed for several days.

DNS, meaning the site and the mail

DNS records are the sort of thing you set once and forget about - right up until somebody (sometimes the host, sometimes the registrar, sometimes me at midnight) changes something in them.

I have three DNS monitors:

  • the A record for the domain - so I know the site points at the server it is supposed to point at. Particularly useful during a migration, when I want to see when the change has actually propagated.
  • the MX record - mail. This was my most painful gap. A missing MX shows up as nothing visible: the site works, the panel works, only the mail stops arriving and you find out a week later, by accident.
  • the TXT record with SPF - so my mail still lands in inboxes rather than in spam.

Each monitor has a match mode. "Contains" means the required values must be present and extra records are fine - a safe everyday setting. "Exact" requires the answer to be exactly what you declared, and only that mode will detect an added record, which is what somebody else's interference in your zone looks like. For MX and SPF I keep the exact mode.

When something does not match the expectation, the alert and the monitor details show plainly what I expected and what the resolver answered. That is the whole diagnosis of a DNS failure in a single sentence.

The NAS and other things that are not websites

We have a NAS in the office holding our backups. There is no sense in querying it like a website, so I use a TCP port monitor: the application simply opens a connection on the given port and measures how long it took to establish. It answered - it works.

This has one practical advantage over checking the panel over HTTP: a NAS web interface can be slow to wake up, and then an ordinary HTTP check may raise a false alarm even though the device was available the whole time. The port answers immediately, so the alerts are real rather than nervous.

If something sits on a slow link anyway and the odd false alarm still happens, there is a reduced sensitivity option - the monitor then gives the device more time to answer before calling it unavailable.

I do not have to be the only person who sees this

This was the last thing I set up, and it is a shame it was not the first. Before that every alert went to me alone, so when I was on holiday or simply out of range, the outage waited for my return.

Now one of my staff has their own free account and is added to my team. It looks like this:

  • Their account is independent of mine. We do not share a login, and I do not have to give them access to my settings or my billing.
  • I share selected monitors with them, not everything. They see the statuses and statistics of the sites and services they are actually responsible for.
  • They set their own alerts and their own notification channels. I have ntfy on my phone, they prefer e-mail and browser push. We do not have to agree on this.
  • By default they can only view - they will not delete or reconfigure a monitor of mine. If I want to give somebody more, there is a separate editor permission: they can change the settings of shared monitors, but still cannot add new ones or delete existing ones.

The effect is simple: an outage alert in the middle of the day reaches two people at once, and whoever is free reacts. An outage both people know about within a minute stops being a crisis.

If I were starting again

The order I would repeat:

  1. An HTTP monitor on the home page and the two most important subpages, every 1-5 minutes, with alerts to e-mail and phone.
  2. SSL certificate monitoring, warning 30, 14 and 7 days before expiry. Certificates expire exclusively at weekends.
  3. Health monitoring with a regression alert - this is the thing that watches deployments and SEO changes.
  4. DNS monitors on A, MX and SPF. Especially MX.
  5. A content monitor with a phrase that must be on the page, and an error message that must not.
  6. A TCP port monitor on the NAS and other devices that are not websites.
  7. A second team account with access to the monitors and its own alerts.

That is about half an hour of configuration in total. In exchange I stop guessing whether "something changed after that update" - I simply see it, with the date and the time.