Monitoring: knowing a service is down before customers do

“Your site is down.” When a customer is the one saying it, the outage has already cost twice: the service lost for the whole time nobody knew, and the trust of the person who found out. Monitoring does not prevent outages. It shortens the time between the moment something breaks and the moment someone who can fix it knows.

This guide from our Infrastructure and cloud section describes what monitoring should watch, who should receive the alert, and how to avoid the most common trap: the alert nobody reads any more.

Why outages are discovered too late

Because a stopped service does not complain. A server that has gone down sends no message, a night job that did not start leaves no error, a form that no longer saves anything keeps showing its thank-you message. Without a dedicated setup, the first alert comes from outside, and often late.

Google’s reference book on running its services, Site Reliability Engineering, sets out the two questions monitoring must answer: what is broken, and why. The first is handled from the outside, the second from the inside.

What to watch: four layers

1. The outside: test as a user would

Google’s book distinguishes two approaches. Black-box monitoring tests externally visible behaviour, as a user would see it; white-box monitoring relies on metrics exposed by the system itself, logs included. The first tells you what is broken now; the second helps you understand why, and sometimes see it coming.

For a mid-sized company, the first is the most urgent: a probe that calls each service every minute, from somewhere other than the server being watched. A probe installed on the machine it watches goes down with it.

2. Wear: what warns before the outage

The same book singles out four golden signals: latency, traffic, errors and saturation. For a business server, saturation shows first on disk and memory: a disk filling up with logs will sooner or later stop the database that writes to it.

Certificates deserve a place of their own, because their lifetime is getting shorter. Let’s Encrypt has announced a gradual reduction of its certificates, currently 90 days:

1. 13 May 2026

   45-day certificates available on request, for early adopters.

2. 10 February 2027

   The default profile moves to 64 days.

3. 16 February 2028

   The default profile moves to 45 days.

Let’s Encrypt states that most users who renew automatically will not have to change anything, discourages manual renewal and recommends monitoring for missed renewals. The shorter a certificate, the sooner a broken renewal shows: to customers.

Backups, finally, are a sign of wear like any other: a backup that has been failing silently for weeks is an outage waiting for its moment. Our guide to backing up your own server details what to check, and how often.

3. The result: a service can respond and no longer work

This is the most often forgotten layer, and the one that costs the most. A probe that gets a correct response concludes that everything is fine. It does not know whether the work was done.

On Palmora Property, a property portal we operate, publishing safeguards block an empty import before it can publish a site with no properties at all, when the job that would have done it would have finished “successfully”. That check is on the result, not on the state of the program.

The lesson is the same in both cases: watch what is really produced, not what is configured. Our guide to monitoring n8n workflows details these checks on the result.

4. Silence: the absence of a signal is an alert

A job that no longer starts produces no error. The answer is to watch for what should happen: the night’s backup sends a signal when it finishes, and it is the absence of that signal at the expected time that triggers the alert. The principle applies to everything that runs on a schedule: imports, reports, synchronisations.

Who receives the alert, and to do what

Monitoring is only worth what happens after the alert. Google’s book puts it in one rule:

In practice:

• one named person per service, with a stand-in for absences, not a shared inbox everyone assumes someone else reads;
• one written action per type of alert: what to check first, who to notify, when to trigger the recovery plan;
• two levels: what must wake someone up, and what can wait until the next morning;
• no permanent alerts: an alert that goes off every day with no consequence teaches the team to ignore them all.

Monitoring does not replace the people who administer the systems: it gives them the signal in time, and the context to act. Nor does it replace the plan that says what to do when the outage is serious, which we detail in the disaster recovery plan.

Where to start

1. 01List your services

   Visible to customers or teams, each with a person who answers for it.

2. 02Set up an external probe

   On each one, outside the server being watched, with an alert to that person.

3. 03Add the signs of wear

   Disk, certificates, backup success.

4. 04Watch one result per service

   A request saved, an import that contains items, a report sent.

5. 05Review the alerts every month

   Remove those that called for no action, add those that were missing.

Monitoring is part of the infrastructure foundation shared by your projects, just like access and backups. The other articles in the section cover neighbouring decisions: the five items that inflate a cloud bill, dedicated server, VPS or cloud, Kubernetes and mid-sized companies, self-hosted n8n in production, which tools to move out of SaaS first, the three-year cost of leaving SaaS, cloud migration without breaking things, dependence on the American cloud and NIS2 in France, whose reference framework counts monitoring among its objectives.

For your self-hosted tools, the managed service option of our Leaving SaaS offer covers monitoring, updates and tested backups. For a setup on existing infrastructure, tell us about your services.

Frequently asked questions

Sources

1. Google, Site Reliability Engineering, chapter Monitoring Distributed Systems (new tab)sre.google
2. Let’s Encrypt, Decreasing Certificate Lifetimes to 45 Days, December 2025 (new tab)letsencrypt.org