Situation
Twenty-plus services share a set of Linode VPS hosts. Without monitoring, a full disk, a leaking worker or a dead endpoint usually shows up first as a user complaint. I set up the monitoring, and I’m the one who reads it.
Sources
- VPS hosts — CPU, memory, disk
- Services — HTTP availability
Collection
- Prometheus scrapes host metrics
- Uptime Kuma checks the services
View
- Grafana dashboards
- Uptime Kuma status + history
Me
- Spot the change
- Investigate: logs, workers, resources
- Prometheus + Grafana: CPU, memory and disk on each VPS.
- Uptime Kuma: scheduled availability checks, with history for each service.
What usually breaks
Most services are Laravel apps with background queues, so the same patterns repeat:
- Out-of-memory kills. A PHP process or queue worker grows until the kernel or PHP stops it.
- Stuck queue workers. Horizon or
queue:workexits, hangs, or keeps running old code after a release. Availability checks stay green while jobs pile up. - Slow drift. Disk and CPU creep up over days. I fix those on a weekday, before they become an outage.
How I handle an incident
- Stabilize. Restart the stuck worker, roll back the bad config, free the disk. Users come first.
- Narrow it down. Whole host or one service? Then PHP-FPM and Supervisor status, then the app and worker logs around the time the signal changed.
- Confirm. Watch the same graph or check return to normal.
- Tell the team what happened, what I changed and what still needs a follow-up.
- Make it stick. If the fix belongs in the pipeline or the server setup, it goes there. Several pipeline guards started this way.
Result and limits
- In some cases this caught degradation before users reported it. I don’t have a measured lead time, so I don’t give a number.
- Dashboards and incident timelines stay private. Centralized logs (Loki) and structured alerting are next, on the homelab roadmap.