Setting up uptime and monitoring checks
Get alerted before your customers notice, with the checks that actually matter.
Monitoring is how you learn about a problem from a graph instead of from an angry customer.
What to monitor
Availability — is the site/service responding? This is the one you cannot skip.
Response time — a site that responds in 8 seconds is effectively down.
Certificates — expiry days in advance, not hours.
Resources — CPU, RAM, disk, load.
Backups — did last night's job actually succeed?
Set up checks here
In /panel/monitoring add a check per service:
HTTP(S) for websites — expect 200, and alert on 4xx/5xx or timeouts.
TCP for non-HTTP services (databases, mail, streaming).
Ping for basic reachability.
Keyword checks for pages that return 200 with an error message inside — the sneakiest outage.
Set the interval sensibly: 1–5 minutes for customer-facing services.
Alerting that you will not ignore
Route alerts somewhere you actually look — email is fine for low severity, chat/push for critical.
Do not alert on everything. Noise trains you to ignore alerts, which is worse than no alerts.
Use severity levels — a disk at 70% is a notice; a site down is a page.
Alert on symptoms, not causes, where you can: "site is not answering" beats "CPU is 80%".
See Monitoring alerts that matter.
Self-hosted monitoring
If you want full control:
Uptime Kuma — friendly uptime monitoring (MIT).
Gatus — config-as-code health checks (Apache-2.0).
Prometheus + Grafana — the standard metrics stack for deeper observability.
Netdata — instant per-host dashboards.
Prometheus collection on Linux uses node_exporter.
The golden rule
Monitor from outside the thing you are monitoring. A monitor running on the same server cannot tell you the server is down. Use our checks (external) as well as any host-level ones you run.
Related reading