Pracandy
← Newsroom

Features

What to Monitor on a One-Person Server

If you are trying to monitor small vps, the answer is simple: watch disk space, memory pressure, failed systemd units, certificate expiry, and timer…

23 October 2026

Ask AI about this story

Münster, Domplatz, Sparschwein 2022 0863
Photo: Dietmar Rabich, CC BY-SA 4.0, via Wikimedia Commons

The Signals That Matter

If you are trying to monitor small vps, the answer is simple: watch disk space, memory pressure, failed systemd units, certificate expiry, and timer execution. You do not need a complex observability stack. You need five specific checks that tell you if the box is failing. One person cannot triage noise, so the system must only alert on true failures.

Resource Limits

With 12GB of RAM and a 193GB disk, the hardware is sufficient for the current load. However, processes on one box compete for memory. A single memory leak in the Next.js process can starve the PostgreSQL 16 database. Monitor for sustained high memory usage rather than spikes. Disk space is equally critical. Static builds for GamingCap and Invoiceful sit on the filesystem, but log files and database growth consume space quietly. Set an alert for when usage exceeds 80%. If the disk fills, the system stops. There is no recovery time.

Signpost at Lizard geograph.org.uk 1780287
Photo: Stephen McKay, CC BY-SA 2.0, via Wikimedia Commons source

Service Health

Instalaz runs as a separate Node process on port 3050, proxied by Caddy. The main Next.js application serves four sites via host-based routing. If the Node process crashes, the proxy returns an error. systemd detects this immediately. Configure alerts for failed units. Do not rely on uptime checks from the outside, as they may lag. Local state is faster and more accurate. Also check certificate expiry. Caddy handles Let's Encrypt automatically, but if the renewal fails, the site goes down. A simple check for days remaining ensures you catch renewal failures before users do.

Scheduled Work

Scheduled jobs run as systemd oneshot services with timers. These are not cron jobs. A timer can fail silently if the underlying service errors. Verify that the last execution completed successfully. If a job fails, the system does not retry automatically. You must know it failed. This is the most common source of silent data loss. The timer ran, the service started, and the service died. Without checking the unit status, you assume it worked. It did not. For more on managing independent tools, see GamingCap guides.

Keep the alert list short. If an alert fires, you must act on it immediately. If you ignore an alert, you will stop looking. Fewer alerts that are always true beat a dashboard nobody opens. The goal is to know when the system is broken, not to watch it breathe.