Minimum Viable Monitoring for One to Five Servers

Put the outage detector outside the server

Your site times out, SSH hangs, and the monitoring page will not load either. Running the monitor beside the application lets the same failure silence both. Put the availability checker on an independent machine or use an external monitoring service, with notifications that do not depend on the application server.

A separate container does not provide that independence. Neither does a different virtual machine that shares the same underlying host. For self-hosted monitoring, choose a machine outside the application's likely outage boundary, preferably with a different infrastructure provider.

If your only machine is the production VPS, start with an external service for public uptime checks. You can still collect host metrics locally, but those graphs cannot reliably announce that their own server has vanished. An always-on machine elsewhere can run your checker, provided you accept that its network connection becomes part of your monitoring.

The notification route needs the same treatment. Email delivered by the failing VPS is a poor emergency channel. Use a destination you routinely notice, and make sure its delivery infrastructure survives the failure you are trying to detect.

Choose Uptime Kuma by default, Gatus for Git workflows

For a small fleet starting with Ubuntu 24.04 LTS, we would choose Uptime Kuma unless the team already manages operational configuration through Git. Its browser interface suits an operator who wants to add an HTTPS check and attach notifications without maintaining another configuration repository. HTTP checks, response-content checks and notifications are documented in the Uptime Kuma project.

Choose Gatus when reviewing monitoring changes alongside application changes is useful to you. Its self-hosted configuration describes endpoints and the conditions their responses must satisfy. That makes a changed health-check expectation visible in a diff, as shown in the Gatus configuration documentation.

Beszel fills a different role in this setup: explaining resource pressure inside the server. Its hub collects metrics from agents and provides history and alerts, according to the Beszel project documentation. We would add it when those signals will change how we respond, rather than installing every available dashboard.

These are open-source projects you can operate yourself. Choose an uptime checker first, then decide whether host history is missing from your incident investigations. Use the Uptime Kuma, Gatus and Beszel comparison when the configuration workflow needs a closer decision.

Check a useful application response

A server answering ping does not prove that your application works. Even a successful HTTP response can be a maintenance page or a cached homepage served while the application is dead. Start with the public HTTPS hostname your users actually visit, then check an application response with a clear meaning.

For a database-backed application, a useful readiness endpoint performs a small, bounded database read and returns a stable health value. Give the dependency check a timeout so the probe cannot hang indefinitely. Keep the response free of credentials and internal diagnostics, and prevent caches from serving an old healthy result.

• Public HTTPS check: require the intended success status and an application-specific response value.
• Certificate check: keep certificate validation enabled and arrange an expiry warning with time to repair renewal.
• Background-work check: watch successful completion or the age of pending work when requests depend on a worker.
• Backup check: watch for overdue successful completion, even if the website remains available.

Keep checks cheap enough to run during an incident. A health request should not create real orders or repeatedly scan a large table. Exercise the endpoint against a deliberately unavailable dependency in a safe environment so you know its healthy response is meaningful.

If you serve through a CDN, distinguish the public path from the application origin. A cached response can keep the public check green while uncached work fails. The reverse proxy, load balancer and CDN guide helps you identify which component each check actually exercises.

Collect host signals that change your response

Host metrics earn their place when they explain an outage or warn you early enough to prevent one. Start with disk space and memory pressure, then keep CPU history for investigation. Avoid turning every movement on a graph into a notification.

Watch the filesystems that hold application data and database files, not only the root filesystem. Set a free-space warning that leaves room for ordinary growth while you investigate. Consider inode exhaustion separately when the workload creates many small files, because available bytes do not guarantee that another file can be created.

For memory, inspect available memory and signs of pressure rather than treating filesystem cache as wasted capacity. Process termination by the kernel deserves investigation, particularly when it restarts a database or worker. Brief CPU bursts during deployment are usually less urgent than sustained saturation accompanied by slow application responses.

Use Beszel for the supported resource metrics you need, and verify that every relevant data filesystem appears. Do not assume a default dashboard covers every condition above. If a required signal is absent, add a focused check for it instead of treating a nearby graph as equivalent.

Keep enough history to compare an incident with an ordinary operating period, and cap retention before monitoring data becomes its own disk problem. Treat missing or stale host data as unknown health. A graph whose last sample looks normal does not prove that the server is still operating.

Turn failures into actionable notifications

Send an urgent notification when someone needs to act before the next routine review. Public application failure usually qualifies; a brief resource spike usually does not. Capacity warnings should arrive while you still have time to schedule the fix.

For an ordinary small web application, checking each minute and alerting after consecutive failures is a reasonable starting policy. Choose the failure window from how long users can tolerate an outage. Include probe timeouts and notification delivery in that delay, then verify the resulting behavior rather than assuming the polling interval is your detection time.

Each alert should identify the affected service and the failed condition. Include a link to the relevant check and a short first action, such as checking the application service journal. Assign an owner so a shared chat message does not become everyone else's problem.

Enable recovery notifications and require sustained recovery if the service repeatedly flips between states. Suppress duplicate symptoms when a host outage explains several failed checks. Any maintenance silence should expire automatically, because an abandoned silence can hide the next real incident.

Watch scheduled jobs with a deadline for successful completion, not only an alert emitted by the failing job itself. A scheduler that never starts cannot send its own failure message. For backups, send the success signal after the intended remote copy finishes, and keep restore verification separate using the VPS backup and recovery guide.

Protect the monitoring system and watch it fail

Your monitoring system holds a map of the infrastructure and often credentials for notification services. Keep administrative access private where practical, using authenticated access over an encrypted connection. If you publish a status page, expose only information that belongs in public.

Avoid giving the uptime checker access to the Docker socket when an HTTP request answers the operational question. Access to that socket can grant control over the host's Docker daemon. Mounting the socket read-only does not make its API read-only, a risk covered by the Uptime Kuma Docker monitoring documentation.

Apply the same privilege review to host agents. Enable container inspection only when you need it, and understand what credentials or host interfaces the agent can access. Keep notification secrets out of Git and use the Ubuntu hardening checklist for the machine running your monitor.

A self-hosted checker also needs an independent watcher. Checking that its web interface answers catches some failures; detecting stalled checks requires watching fresh check activity or a heartbeat tied to that activity. The watcher must send its alert without depending on the monitoring machine it watches.

Back up the monitor's configuration and protect any credentials included in that backup. Record how to rebuild checks if its database disappears. If you cannot yet provide independent monitoring of the checker, document that blind spot explicitly and keep an external availability check for the production application.

Give Claude Code evidence, withhold automatic repairs

We use Claude Code for bounded investigation: reviewing recent service logs against an alert and proposing the next diagnostic step. Give it the affected service and incident window, with a defined set of permitted reads. A short evidence packet is more useful than unrestricted access to the entire machine.

Ask for observed facts separately from possible causes. An alert saying the readiness endpoint failed does not establish that the database needs restarting. Require the proposed action to identify what it changes and how you will verify recovery.

Do not connect a resource threshold directly to agent-written repair commands. Deleting files to clear disk space or restarting a database can destroy evidence and worsen an incident. Require explicit approval for changes, and reserve unattended remediation for narrow procedures you have already reviewed and exercised.

Treat log messages and response bodies as untrusted input, because attackers can place instructions in them. Keep secrets out of the investigation context unless access is necessary and controlled. The production guardrails for AI agents provide the boundary to establish before handing an alert to Claude Code.

Verify an alert reaches your phone today

Create the external HTTPS check for your application and attach the notification destination you intend to use during an outage. Send the destination's test message, then inspect it on the device you normally carry. Check notification permissions and quiet-mode behavior while you have time to fix them.

Next, duplicate the application check and label the duplicate as an alert drill. Configure its expected response content to require a string that you have verified the endpoint does not return, keeping its notification destination attached. Let the ordinary failure policy trigger rather than using the notification test button.

Restore the duplicate's correct response expectation and wait for its recovery policy to complete. Confirm recovery delivery, then remove the drill check and leave the real application check enabled. Record the observed alert delay and repeat the drill after changing notification credentials or delivery settings.