Monitoring needs two views: an outside check that proves customers can reach the service, and an inside check that warns when the server is running out of a resource.
The LayerOne status page reports incidents and maintenance affecting the LayerOne platform. It does not monitor your VPS, domain, application, or certificate.
Monitor from outside the server
Use an independent monitoring service or a system in another network. A check running on the VPS cannot report that the VPS or its network path has failed.
For a web application, monitor a dedicated endpoint such as /health that:
- returns a successful status only when the application can serve requests
- checks critical dependencies without exposing secrets or internal details
- responds quickly and does not perform expensive work
Also monitor certificate expiry and DNS resolution. For non-HTTP services, use a TCP connection check or a protocol-specific check instead of relying on ping alone.
Watch resource pressure inside the guest
The server's Usage Graphs tab helps with CPU, memory, disk I/O, and network trends. It is a capacity view, not an application uptime monitor and not an alerting service.
At minimum, collect and alert on:
- filesystem space and inode use:
df -handdf -i - memory and swap pressure:
free -h - failed services:
systemctl --failed - load and sustained CPU use:
uptime - application errors and restarts:
journalctl -u yourservice - database availability and storage growth
Set thresholds for the workload rather than copying a universal percentage. Disk space deserves both an early warning and an urgent alert because a full root filesystem can stop logging, databases, package updates, and SSH sessions.
Route alerts somewhere that will be seen
Use at least one channel that is independent of the monitored server. Include the hostname, service, check name, failure time, and a direct link to the relevant dashboard or runbook. Avoid putting passwords, API keys, or sensitive response bodies in alert messages.
Prevent one failure from sending hundreds of messages: require more than one failed check before paging, group duplicate alerts, and send a recovery notice when the service is healthy again.
Test the complete path
A green dashboard does not prove the notification works. During a maintenance window, deliberately fail each important check:
- Stop the test service or block the monitored port.
- Confirm the monitor detects the failure from outside.
- Confirm the notification reaches the intended person.
- Restore the service and confirm a recovery notification arrives.
Repeat after changing firewall rules, DNS, certificates, or notification providers.
When an alert fires
Check the LayerOne status page for a platform incident, then work through Troubleshooting a server you cannot reach. Open a ticket with the instance id, time of failure, exact error, and relevant command output if the evidence points outside the guest.