Uptime Kuma vs Gatus vs Beszel: Pick Your Monitoring

Match the tool to the failure you need to catch

Assume your application runs on a single VPS with Ubuntu 24.04 LTS. You need to know whether someone outside that server can reach the application, and whether the server is running out of capacity. These are different observations: an idle machine can serve a broken application, while a busy machine can still serve requests correctly.

We would start with Uptime Kuma unless your team already manages operational configuration through Git. In that case, Gatus fits the existing review process. Add Beszel when missing resource history makes incidents difficult to explain, rather than installing every dashboard before defining an alert.

The decision is about the work you will maintain after installation. A dashboard nobody trusts becomes another application to patch. Use the minimum monitoring plan for a small server fleet to define coverage before expanding the stack.

Use Uptime Kuma when browser configuration fits your team

Uptime Kuma provides browser-managed monitors, notifications and public status pages. Its checks include HTTP requests with keyword or JSON conditions, so you can inspect the response instead of accepting any successful connection. The official Uptime Kuma project documents the supported monitor types.

We recommend this workflow when the person answering alerts wants to adjust a check without editing a deployment repository. Keep monitor names tied to user-visible services, such as account login or the application API. Names based only on container identifiers become difficult to interpret during an incident.

The operational tradeoff is change history. If your team makes edits directly in the interface, require a short record of why a check changed and who owns it. Back up the application state, and treat changes to notification destinations with the same care as changes to the checks themselves.

Put checks in Git when Gatus matches your workflow

Gatus defines endpoints and their success conditions in YAML. Conditions can inspect response status and body content, and checks can trigger notifications. Its official configuration reference also explains persistent storage for monitoring history.

We prefer this approach when monitoring changes belong in the same review queue as application changes. A pull request can show that a deployment introduces a new health endpoint and updates its check. Reviewers can question a weakened condition before it reaches the running monitor.

That benefit depends on discipline. Keep credentials outside the repository, and confirm that the deployed configuration matches the reviewed commit. A successful deployment does not prove that an endpoint is covered or that its notification route works.

Git preserves configuration, but it does not automatically preserve monitoring history. Decide whether historical results matter to your incident reviews and configure durable storage accordingly. Rebuilding a monitor should be a documented operation, including restoring any state you intend to keep.

Add Beszel when resource history changes your decisions

Beszel uses a hub and agents to collect server metrics, including container resource history. It supports metric alerts and gives you a place to inspect activity around a failure. The Beszel architecture and metrics documentation describes what the agents collect.

This is useful when an application recovers before you can inspect the machine. Historical memory pressure or disk activity gives you a lead that a current process listing cannot provide. Treat a matching spike as evidence to investigate, not proof that you have found the cause.

Beszel also supports network checks, including HTTP and DNS, executed from its agents. That creates overlap with dedicated uptime tools, but the probe location still determines what a result means. A check originating on the application server does not establish that an outside visitor can reach it. The Beszel network monitoring documentation explains this agent-based model.

Add it when you have a specific diagnostic gap, such as unexplained slowdowns during background jobs. Use that history to guide Ubuntu server performance tuning, and change one suspected constraint at a time. More graphs should produce better decisions, not a longer daily inspection routine.

Place availability checks outside the application VPS

A monitor on the application VPS disappears when that VPS loses power or connectivity. Putting it in a separate container does not remove that shared failure. Local monitoring can still help with diagnosis, but it cannot reliably report the complete loss of its own host.

For a single application VPS, use an external monitoring service or run your uptime monitor on another machine with independent connectivity. If you are keeping everything local temporarily, document the blind spot and add an independent check before relying on alerts. Hosting the monitor elsewhere matters more than switching between these applications.

Check the public hostname over HTTPS so the request follows the route visitors use. Pair that with an application health endpoint that exercises a necessary dependency when appropriate. A cached landing page can remain available while the application behind it fails.

Keep the health endpoint cheap and free of sensitive output. It should reveal whether the required operation succeeded without returning database errors or credentials. Also consider where your status page lives: a page hosted beside the failed application may be unavailable when users need an explanation.

Alert on failures that require a response

Start with a public application check and a notification destination someone actually watches. Use a response condition that distinguishes your application from a generic proxy page. A green connection check is weak evidence if the returned page can still be an error screen.

Allow brief interruptions where your service can tolerate them, but set the delay deliberately. The check interval and failure threshold together determine how long detection takes. Require stable recovery before sending a recovery message if the service tends to alternate between healthy and unhealthy.

• Page someone for sustained failure of a user-facing operation.
• Send capacity warnings to a quieter channel while there is time to act.
• Include the affected service and an initial investigation step in the notification.
• Give maintenance suppression an expiry so it cannot silently become permanent.

Avoid paging on every short CPU burst. A scheduled job can consume spare CPU without harming users, while steadily shrinking disk space may require action before anything fails. Set thresholds around the service's normal behavior and the time needed to respond.

Protect monitoring state and bound agent access

Monitoring needs its own recovery plan. Preserve the configuration and persistent data needed to rebuild it, and keep a backup outside its host. If you deploy with containers, follow the Docker Compose production checklist for durable storage and restart behavior.

Keep administration behind authenticated access and publish only the service information users need. Check public pages for internal hostnames or detailed failure messages before exposing them. Monitoring credentials should have only the permissions required to perform their checks.

Claude Code is useful for drafting check definitions and reviewing changes against your intended coverage. Give it read-only investigation access by default, with secrets excluded from prompts and repository content. Require approval before it disables a monitor or changes where alerts go.

Do not let an agent make an incident disappear by relaxing the condition that detected it. Ask it to explain the failed observation and propose a separate corrective change. The production guardrails for AI agents provide a practical boundary between investigation and actions that alter service behavior.

Prove an alert reaches you before adding more checks

Create your first application check in the selected tool and assign its notification route. Inspect the actual response from the monitor's location, then confirm that the success condition matches the intended application behavior. Do not copy a condition without checking what your endpoint returns.

Create a temporary duplicate of that check, label it as a drill, and give it a deliberately impossible success condition. Route it through the same notification destination and allow the configured failure threshold to elapse. This exercises failure detection without interrupting the application.

Restore a valid condition on the duplicate and confirm recovery delivery is enabled. Wait for recovery, then remove the drill check and record the result in your operations notes. If you added Beszel, confirm that incoming samples are fresh before relying on its historical charts.

Finally, repeat the notification drill after changing alert credentials or moving the monitor. The duplicate-check drill proves delivery through the configured route; it does not prove coverage of a complete VPS outage. Before calling the setup ready, verify that at least one availability probe runs outside the application host.