The downtime alarm: know your site is broken before your customer does
One free watchman pings your phone the minute your website, booking page or backup fails
Version history
One free program watches your website, booking page and nightly backups — and pings your phone within a minute when something breaks. The first quick win in this library: one container, one hour.
The problem
Most small businesses find out their website is down from a customer. That call comes hours or days after the break — and for every customer who phones, more just gave up and booked elsewhere. Same story for the quieter failures: the security certificate that expires and greets visitors with a browser warning, the domain renewal that slips past, the nightly backup that stopped running in March and nobody noticed. The monitoring services that watch for this charge EUR 7-35/month, and the free tiers keep shrinking — UptimeRobot's free plan is now restricted to non-commercial use. And there's a second reason this blueprint exists: nearly every other blueprint in this library puts another service on your small server. Booking page, invoices, password vault, document archive. So who watches the server? This is the smoke detector of your digital shop — you install it once, and it only speaks when something burns.
The architecture
▲ checked every 60 seconds, from the outside
│
[ Uptime Kuma — on a SEPARATE small box, Docker ]
├─ HTTP check with keyword: the page loads AND says the right thing
├─ certificate expiry: warning at 21 / 14 / 7 days
├─ push monitor: backup script reports in nightly — silence = alarm
└─ public status page for customers (optional)
▼ on failure — and again on recovery
[ ntfy → push on your phone ] or [ Telegram / email ]
One design decision carries this whole blueprint: the watchman does not live in the building he guards. If the monitor runs on the same server as your booking page and that server dies, the alarm dies with it. So Uptime Kuma goes on a second, separate box — a EUR 4-6/month mini-VPS, or a Raspberry Pi on the shop's shelf. Everything else is configuration in a web page, not code.
Tool choices — and why
Uptime Kuma (MIT, 89.3k stars, v2.4.0 released 31/05/2026) is the default and it isn't close. It is the most-starred self-hosted monitoring tool on GitHub, runs in one Docker container on 256 MB of RAM, and everything is point-and-click: website checks, keyword checks, certificate expiry warnings, domain expiry (added in v2.1, 02/2026), a status page builder, and 90+ alert channels. Unlimited monitors, 1-minute intervals, EUR 0. The paid services sell exactly this feature list for EUR 7-35/month.
ntfy (Apache-2.0, 30.5k stars, active — last push 30/05/2026) puts the alert on your phone as a real push notification, without giving your number to anyone. Self-host it next to Kuma, or use the free public ntfy.sh service — install the app, pick a topic name, done in five minutes. If you already use Telegram (several blueprints in this library do), skip ntfy and reuse your Telegram bot: one alert channel fewer to maintain.
Healthchecks (BSD-3-Clause, 10.1k stars, v4.2 released 28/04/2026) is the alternative, not a third container to run. It specialises in one thing: watching scheduled jobs — backups, exports, sync scripts — and alarming on silence. Uptime Kuma's push monitor covers that same need well enough for most small setups, which is why Kuma alone is the recommendation here. Pick Healthchecks instead if scheduled jobs are your main worry and website checks are secondary; its hosted service also has a free tier for 20 checks if you want the dead-man's switch to live completely outside your own hardware.
Monthly cost. Software: EUR 0, all three. Hardware: EUR 0 if a Raspberry Pi or any always-on second box is available; otherwise a mini-VPS at EUR 4-6/month. Alerts: push via ntfy and Telegram are EUR 0; SMS is optional and pay-per-message. Realistic total: EUR 0-6/month.
Setup outline
1. Pick the watchman's box — any machine that is NOT the server being watched. Mini-VPS or a Pi at the shop both work.
2. Start Uptime Kuma with the official Docker image (one command, the project's README has it). Open the web page, create the admin account.
3. Add your public-facing monitors: website, booking page, webshop. Use HTTP keyword checks — the check passes only if the page contains a phrase that should always be there, like your business name in the footer.
4. Turn on certificate expiry notifications (21, 14 and 7 days) for every HTTPS monitor. Add a domain expiry check for your domain name.
5. Connect the alert channel: ntfy or Telegram. Send the test notification and see it arrive on your phone before going further.
6. Add a push monitor called "nightly backup" and append its one-line ping command to the end of your backup script (the 3-2-1 backup blueprint's script has an obvious place for it). If the backup doesn't report in within 24 hours, your phone rings the alarm.
7. Set retries to 2-3 before a monitor counts as down — you want alerts, not jitter.
8. Optional: build the status page, put it on a subdomain like status.yourbusiness.example, and link it from your contact page.
Pitfalls — the real ones
The watchman inside the building. The most common mistake: installing the monitor on the same server as everything else because it's convenient. Total server failure — the one scenario you most need an alarm for — then produces no alarm. Separate box, no exceptions.
A page can be broken and still "up". A plain reachability check is satisfied by an error page or a half-rendered shop. Keyword checks catch what a ping cannot: the page loads and still says what it should.
Alert fatigue kills the alarm. If your phone buzzes for every 10-second network hiccup, you'll mute it within a month — and then miss the real one. Retries before alerting, 60-second intervals, and alert only on the monitors that matter. Ten well-chosen monitors beat forty noisy ones.
Alerts through the thing that's down. If alerts go only to the email hosted on the server being watched, a dead server sends no mail. At least one channel must be independent — push or Telegram.
Don't overshare on the status page. Show customers "website" and "online booking". Don't list your vault, archive or internal tools — a public status page that names everything you run is a map for the wrong audience.
Verified repos
Uptime Kuma — MIT, 89.3k stars, v2.4.0 (May 2026)
ntfy — Apache-2.0, 30.5k stars, active (May 2026)
Healthchecks — BSD-3-Clause, 10.1k stars, v4.2 (April 2026)
Get the next blueprint as it publishes — free, practical, verified tooling only.
Subscribe · Want this audited or extended for your business? DM @RXed_EU
Get this blueprint tailored to your business — free
Tell us what you run and where. We research your sector's specifics — rules, tools, customer habits — and send you a version of this blueprint rebuilt for your situation, usually within 24 hours.