Self-hosted or external monitoring: how to choose

A monitoring script is twenty lines. That is exactly why the question deserves an honest answer rather than a sales pitch: for a single site with modest stakes, writing your own is often the right call, and nobody has an interest in telling you so.

The comparison, on the criteria that decide

Only one row of that table is disqualifying, and it is the fourth. Everything else can be made up for with time; a probe that dies with the machine it watches cannot. It is worth pausing on that row, because it is the one people wave away at the design stage and remember at three in the morning: the scenario your monitoring exists for is precisely the scenario in which a probe hosted on the same machine has already stopped.

Write it yourself: when it is the right call

One site, one server, one person. A cron job that curls your homepage and emails you on a non-200 works. It costs an evening and nothing per month.

Special needs. Checking something inside your application, a queue length, a business figure, a specific database state: no external service can do that without access you should not be giving.

You enjoy it. A legitimate reason, and often the strongest. A script you wrote is a script you will know how to repair.

One condition in all three cases: the probe must run somewhere other than the machine being watched. A five-euro machine at a different provider, or a scheduled run at a third party, is enough. Without that, you have written a tool that goes quiet exactly when it should speak.

The three walls you eventually hit

The check runs on the machine being watched. If the server goes down, so does the script. The outage nobody detects is precisely the one where everything is down at once, and that is the one you built it for.

History disappears. Knowing the site is down right now is the easy half. Answering "how available was it last month" requires storing every check, handling retention, and knowing how to recompute a percentage when a maintenance window was planned. That is where a weekend project turns into a small database to maintain.

It multiplies badly. One site, twenty lines. Twenty sites, a rota of intervals, false alarms to tune, alerts that go quiet without anyone noticing, and a client asking for a monthly report. Running an estate is a job in itself, and it is not the job the script was written for. The transition is rarely a decision either; it happens gradually, one site at a time, until an afternoon disappears into maintaining something that was meant to take an evening.

The four traps of a home-made script, in the order you meet them

None of them is insurmountable. All of them are discovered afterwards, which is the problem.

The alert email does not arrive. A server sending mail from its own IP address ends up in spam, or nowhere. You find out on the day you were expecting the alert, which is to say too late. The fix is simple, a transactional sending service, and it adds one more dependency to watch.

The script stops without saying so. A language update, a changed path, a quota reached: the scheduled task fails silently. A monitoring script needs monitoring, which is logically uncomfortable and practically true. The guard is one line: have it send a weekly sign of life, whose absence alerts you.

False positives eventually win. With no confirmation and no memory of state, a script emails on every network hiccup. After three weeks nobody opens them, and the monitoring still exists while serving no purpose.

Nobody else knows how to fix it. On the day you are on holiday, the script is a black box written in a personal style, with no documentation. That is acceptable for a personal site, much less so once a client depends on the answer.

The real cost, in time

This is the only serious argument, and the one comparisons avoid because it does not fit in a price table.

Writing it costs an evening. The rest arrives in slices: an hour when your email provider changes its rules, two hours the day your own probe's certificate expires, half a day to add history when a client asks for it, and an afternoon the first time you discover the script stopped running six weeks ago.

Count one to two days a year, spread across the worst possible moments, always while you were doing something else. Compare that with a subscription, bearing in mind that your day is probably worth more than a year of it.

What an external service actually buys

Not the check itself: you can write that. It buys the outside viewpoint, the history you did not have to store, and the fact that the thing keeps running when your infrastructure does not.

And the part nobody thinks about at the start: someone else maintains it. A monitoring script that stopped working three months ago is worse than no monitoring, because you still believe you are covered. It is the most common silent failure in this whole field, and the only one its victim cannot detect by definition.

The hybrid setup, which is what most serious teams run

This is not a soft compromise, it is the right answer as soon as the system runs past one site.

Infrastructure monitoring stays with you: disk, memory, queues, business figures. It sees what an outsider cannot, and it is allowed to fall with the machine, since the machine is what it describes.

Website monitoring comes from outside: the status code, the response time, the certificate, the expected content on the page. It sees what your visitors see, and it is the only viewpoint that stays valid when everything else is down. It is also the only one that answers the question your host never will.

The two do not replace each other. They answer different questions, and confusing them is the most common cause of monitoring that reassures without protecting.

An honest decision rule

Start from what you would lose during a three-hour outage, and from how many sites you look after. The first figure takes five minutes to work out; the second you already know.

• One site, low stakes → write it yourself, run it elsewhere, and check once a quarter that it still fires.
• Several sites, or a client involved → an external service pays for itself in the time you no longer spend maintaining it.
• Deep needs inside the application → both, doing different jobs.

The same trade-off replays, identically, on a different object: tracking your backlinks in a hand-kept spreadsheet works for a long time, then stops working for exactly the same reasons. The spreadsheet, its seven columns and its expiry date tell the same story with different rows.

And whichever you choose, the interval question remains open: it is settled from cost, not from technology. The first thing to do afterwards, on the day something falls over, is the same in both cases: the first fifteen minutes do not depend on the tool.