Self-Hosted Infrastructure Monitoring Guide 2026
Self-hosting gives you control: over your data, your costs, your configuration, and your stack. It also gives you full responsibility for reliability. There is no AWS support team, no managed service SLA, no platform health dashboard to blame when something breaks. When your self-hosted Nextcloud instance goes down at midnight, your users cannot reach their files — and the only thing between you and an embarrassing outage is your monitoring setup.
This guide is written for teams and individuals running self-hosted applications on VPS (Hetzner, DigitalOcean, Linode, OVH), bare metal servers, or homelab hardware. It covers the monitoring gaps that internal tools like Uptime Kuma, Prometheus, and Netdata cannot fill — and how Vigilmon provides the external vantage point your infrastructure needs.
The Self-Hosted Monitoring Paradox
The most common self-hosted monitoring setup looks like this: Uptime Kuma running on the same VPS that hosts all the applications being monitored. Or Prometheus and Grafana on a server in the same rack as the production machines.
This is better than nothing. But it has a fundamental flaw: when the server goes down, the monitoring goes down with it.
A power outage, kernel panic, full disk, network partition, or OOM event takes out both your application and your internal monitoring simultaneously. From inside the system, everything looks fine — until it doesn't look like anything at all.
External monitoring — a service probing your endpoints from outside your network — is the only reliable way to detect infrastructure-level failures. Vigilmon checks your services from multiple geographically distributed nodes. If your VPS goes dark, Vigilmon keeps checking, detects the failure within minutes, and alerts you.
What Internal Monitoring Tools Miss
Tools like Uptime Kuma, Netdata, Prometheus, and Zabbix are excellent for what they do. But their architectural position — inside your network, on your hardware — creates blind spots:
Whole-server failures: If the machine running your monitoring stack crashes, you have no monitoring. The most critical moment — the total server outage — is exactly when internal monitoring fails you.
Network path failures: Your server is healthy, but the ISP's upstream router is dropping packets. Or your hosting provider has a routing issue in their data center. Internal monitoring sees everything fine. External monitoring sees the service unreachable.
DNS failures: Your apps.example.com DNS record stops resolving — registrar issue, misconfiguration, TTL corruption. Your services are running perfectly; nobody can reach them. Internal DNS monitoring on the same domain won't catch this if it's a registrar-level failure.
SSL certificate expiry: Let's Encrypt certificates expire every 90 days. Certbot renewal fails silently more often than people realize — a misconfigured renewal hook, a failed acme challenge, a firewall blocking port 80. The certificate expires, your site shows a security warning, and you find out when a user emails you.
Geographic routing problems: Your server is in Frankfurt. A CDN misconfiguration or routing table change makes it unreachable from North America. Internal monitoring (also in Frankfurt) sees no problem.
What to Monitor in Self-Hosted Infrastructure
VPS and Bare Metal
External endpoint monitoring: Every public-facing service should be monitored from outside your network. This means HTTP/HTTPS checks on every domain and subdomain serving external users.
TCP port monitoring: For services that expose TCP ports — databases with external access, SSH (for availability checking, not security), game servers, mail server ports — TCP monitoring verifies that the port is accepting connections without needing to run an HTTP health check.
Ping/ICMP monitoring: Low-level availability check. If ICMP is unreachable, the machine is likely down or the network path is broken. Use as a baseline alongside HTTP checks.
SSL certificate monitoring: Monitor expiry dates for every TLS-terminated domain. Alert at 14 days and 7 days before expiry to give yourself time to renew manually if certbot fails.
Services Running on Self-Hosted Infrastructure
Web applications: Nextcloud, Gitea, Forgejo, Vaultwarden, Immich, Jellyfin, Home Assistant — any web service serving external users should have an HTTP monitor.
Reverse proxies: If you're running Caddy, nginx, or Traefik as a reverse proxy, monitor the endpoints they serve. A misconfigured upstream block in nginx will return 502s that only an external check will catch.
Mail servers: If self-hosting email (Stalwart, Postfix, Dovecot), monitor SMTP (port 25 or 587) and IMAP (port 993) availability with TCP checks.
Scheduled jobs: Database backups, Let's Encrypt renewal cron jobs, backup sync scripts — use heartbeat monitoring to verify these complete on schedule.
Setting Up Vigilmon for Self-Hosted Infrastructure
Step 1: Audit Your Public Endpoints
List every domain and subdomain that external users or services access:
https://cloud.yourdomain.com # Nextcloud
https://git.yourdomain.com # Gitea
https://vault.yourdomain.com # Vaultwarden
https://media.yourdomain.com # Jellyfin
https://yourdomain.com # Public site
https://mail.yourdomain.com # Webmail
Each of these becomes a Vigilmon monitor.
Step 2: Create Vigilmon Monitors
-
Sign up at vigilmon.online — free tier, no credit card.
-
For each endpoint, add an HTTP monitor:
- URL: full HTTPS URL
- Expected status: 200 (or 301 for redirect endpoints)
- Check interval: 1 minute
- Enable SSL monitoring: yes
-
For TCP-only services (database ports, SMTP), add TCP port monitors:
- Host: your server IP or domain
- Port: the service port
- Check interval: 1 minute
Step 3: Enable SSL Certificate Monitoring
For every HTTPS endpoint:
- Enable SSL monitoring in Vigilmon
- Set alert thresholds: 14 days and 7 days before expiry
This alone prevents the most embarrassing class of self-hosted outage. Let's Encrypt renewal failures are common and silent. Getting a Vigilmon alert at 14 days gives you two weeks to investigate and fix the renewal before it affects users.
Step 4: Set Up Heartbeat Monitoring for Cron Jobs
Your scheduled jobs — backups, certificate renewals, sync scripts — need heartbeat monitoring. Without it, a failed cron job produces no alert.
Example: Monitor certbot renewal
Edit your certbot renewal cron or systemd timer to ping Vigilmon on success:
# /etc/cron.d/certbot
0 */12 * * * root certbot renew --quiet && curl -s https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID
If renewal fails (the && condition fails), the heartbeat is never sent. Vigilmon detects the missed heartbeat and alerts you — well before the certificate actually expires.
Example: Monitor nightly database backup
#!/bin/bash
# /opt/scripts/backup.sh
pg_dump -U postgres mydb | gzip > /backups/mydb-$(date +%Y%m%d).sql.gz
if [ $? -eq 0 ]; then
curl -s https://vigilmon.online/heartbeat/YOUR_BACKUP_HEARTBEAT_ID
else
echo "Backup failed" | mail -s "ALERT: Backup failed" admin@yourdomain.com
fi
Configure the Vigilmon heartbeat to expect a ping every 24 hours. If backup fails, the heartbeat is missed and you get an alert.
Step 5: Configure Alert Routing
For self-hosted infrastructure, the right alert channel depends on your context:
Personal homelab: Email to your personal address is usually sufficient. Vigilmon sends a recovery notification when the service comes back up, so you get the full incident timeline.
Small team or business: Add a Slack webhook to your operations channel. Everyone sees the alert, and you can coordinate in-thread.
Business with SLA requirements: Use Vigilmon's webhook integration to route alerts to PagerDuty or OpsGenie for proper escalation.
Set a confirmation delay of 2 minutes for most monitors. This means Vigilmon confirms the failure with multiple nodes over 2 minutes before alerting. Self-hosted infrastructure can have brief blips during restarts, cron spikes, or backup operations — the confirmation delay eliminates nuisance alerts for these.
Vigilmon vs. Running Uptime Kuma
Uptime Kuma is excellent open-source software. But running it on the same infrastructure you're monitoring introduces the paradox described above. Here is the honest comparison:
| | Uptime Kuma (self-hosted) | Vigilmon (external) | |---|---|---| | Survives server outage | No | Yes | | Multi-region consensus alerting | No | Yes | | False positive protection | No | Yes | | SSL monitoring | Yes | Yes | | Public status page | Yes | Yes | | Heartbeat monitoring | Yes | Yes | | Maintenance cost | You maintain it | Managed service | | Cost | Free (your server) | Free tier available |
The right answer for most self-hosters: Use both. Run Uptime Kuma for internal visibility (monitoring internal services, LAN endpoints, services not exposed to the internet). Use Vigilmon for external validation of your public-facing services.
Alternatively, run Uptime Kuma on a separate, independent VPS from your main server — ideally in a different data center. This eliminates the colocation problem, though it adds maintenance overhead.
Common Self-Hosted Failure Modes and How Vigilmon Catches Them
Scenario 1: OOM killer terminates nginx
At 3am, a runaway PHP process consumes all available memory. The Linux OOM killer terminates nginx. All web services go down. Internal monitoring on the same server is unreachable.
Vigilmon detects all HTTP monitors going down simultaneously, alerts within 2 minutes.
Scenario 2: Let's Encrypt renewal fails silently
Certbot runs on a schedule but the acme challenge fails because port 80 is blocked by a new firewall rule. The renewal succeeds in dry-run mode but the live renewal fails. The certificate expires in 30 days, then 14 days, then 7 days.
Vigilmon sends an alert at 14 days: "SSL certificate for cloud.yourdomain.com expires in 14 days." You investigate, find the firewall rule, fix it, renew the certificate.
Scenario 3: ISP routing issue
Your hosting provider's upstream router has a BGP misconfiguration. Traffic from North America cannot reach your Frankfurt VPS. Your internal monitoring (also in Frankfurt) sees nothing wrong. Users in the US experience connection timeouts.
Vigilmon's multi-region nodes — including North American nodes — detect the failure. You receive an alert specifying which regions are affected.
Scenario 4: Database backup silently stops running
A system update changes the path to the backup script. The cron job runs but exits with an error. The heartbeat is never sent. Vigilmon detects the missed heartbeat and alerts you — you investigate before data loss occurs.
Building a Status Page for Self-Hosted Services
Even if you're self-hosting for personal or internal use, a status page is useful:
- Communicate planned maintenance to users or colleagues
- Provide historical uptime data for your own records
- Give users a self-serve answer to "is it down for everyone?"
Vigilmon's status page is included on all plans. Set it up at status.yourdomain.com with a simple CNAME record. Display the services you want visible — you can choose to show all monitors or just a curated subset.
Self-Hosted Monitoring Checklist for 2026
External Monitoring (Vigilmon)
- [ ] HTTP monitor for every public-facing web service
- [ ] TCP port monitor for non-HTTP services (SMTP, IMAP, etc.)
- [ ] SSL certificate monitoring enabled for all HTTPS endpoints
- [ ] Heartbeat monitoring for all scheduled cron jobs (backup, certbot renewal)
- [ ] Alert routing configured (Slack, email, or webhook)
- [ ] Public status page at status.yourdomain.com
Internal Monitoring
- [ ] Server resource monitoring (CPU, memory, disk) — Netdata or node_exporter
- [ ] Disk space alerts (alert at 80%, critical at 90%)
- [ ] Log aggregation for application errors
Operational Practices
- [ ] Document the recovery procedure for each critical service
- [ ] Test recovery procedures annually (or after major changes)
- [ ] Verify alerting works by triggering a test incident
Summary
Self-hosted infrastructure demands external monitoring. The internal tools — Uptime Kuma, Prometheus, Netdata — are valuable, but they share the same single point of failure as the infrastructure they monitor. When the server goes dark, internal monitoring goes dark with it.
Vigilmon provides the external vantage point: multiple geographically distributed nodes checking your endpoints every minute, consensus alerting that eliminates false positives, SSL certificate expiry monitoring, and heartbeat monitoring for your scheduled jobs. It is the monitoring layer that survives your infrastructure's worst moments.
Protect your self-hosted infrastructure with external monitoring — try Vigilmon free, no credit card required.