Why alert only after several failures?

Because a single failed check is usually noise - a momentary network blip, a redeploy, a slow response that timed out once. Alerting on the first failure trains you to ignore alerts. Waiting for two or three consecutive failures before paging means an alert almost always reflects a real, sustained outage, which keeps the signal trustworthy and your team responsive.

Do I need a monitoring SaaS for this?

Not for basic uptime alerting. A short script on a schedule that curls your health endpoint and posts to a webhook covers the core need - know quickly when the service is down - with no account and no data leaving your control. A hosted monitor adds value for external vantage points and history, but you should not be blind just because you self-host, and this closes that gap in a few lines.

Where should the monitor run?

Ideally not on the same machine as the service it watches - if that box goes down, so does the monitor, and you get no alert. Run it on a second cheap server, another provider, or anywhere with network access to the endpoint. The generated systemd timer makes it a tidy, supervised job wherever you put it.

Free tool · Runs in your browser

Know before your users do.

Self-hosting doesn't mean flying blind. Point this at your health endpoint and get a monitor that checks it on a schedule, alerts Slack, Discord, or any webhook after a few failures, and pings you again when it recovers — plus the systemd timer to run it. No monitoring SaaS.

URL to monitor

Check every

Alert after N failures in a row

Alert to

Service name (for the alert text)

monitor.sh

systemd timer

Don't learn it from a customer

The worst way to find out your service is down is a message from a user — it means it was down long enough for someone to notice and care, and you had no idea. A monitor closes that gap to minutes: it watches the same health endpoint your supervisor and load balancer use, and the moment it's been failing long enough to be real, you get a ping. Self-hosting is no excuse to be the last to know.

An alert is the start of the story, not the end. What you do with it — whether the service already tried to recover itself, whether there's a known-good version to fail over to, whether anyone has to wake up at all — is the difference between a blip and an incident. Automating that response, across the hosts you own, is what a control plane is for.

Related free tools

Deploy to your own serverPush-to-deploy, your box systemd service generatorKeep your app running Reverse proxy + HTTPSCaddy / nginx + HTTPS Backup script generatorDump, offsite, restore

All free tools →

An alert tells you. A control plane handles it.

Infraveil watches your services, recovers what it can automatically, fails over to a known-good version when it can't, and only escalates to you when a human is genuinely needed — with a tamper-evident record of every step, on infrastructure you own.

See how it works

Get the monitoring & recovery playbook

Watch, alert, and auto-recover a self-hosted backend. No spam.