The common self-hosted tools each cover one half: Uptime Kuma checks whether something answers, Beszel and Glances show what the machine is doing, Cockpit lets you administer it. None of them reads your GitHub account, so repository activity, failed Actions runs, security alerts and the question whether the server runs what is on main stay on GitHub, in a second tab.
What do Uptime Kuma, Beszel, Glances and Cockpit cover?
Each covers the server side, and each a different part of it. The table lists what the projects say about themselves in their own documentation, checked on 9 October 2026; a dash means the documentation does not name it.
| Uptime Kuma | Beszel | Glances | Cockpit | |
|---|---|---|---|---|
| Checks over HTTP, TCP, DNS, ping | yes | yes (network monitors from the agent) | – | – |
| CPU, memory, disk, network | – | yes, with history | yes | yes, history with PCP |
| Containers | Docker container as a monitor | Docker and Podman, per-container history | Docker, Podman, LXD | Podman |
| Alerts | 90+ notification services | configurable alerts | thresholds, alert endpoint in the API | – |
| Install system updates | – | – | – | yes (“Upgrade software”) |
| GitHub repos, Actions, Dependabot | – | – | – | – |
Sources: Uptime Kuma README, Beszel, What is Beszel, Glances documentation and its container page, Cockpit project page and Cockpit PCP metrics, all checked on 9 October 2026.
What does none of them show?
Nothing from the repository side. Uptime Kuma’s README mentions GitHub only as the place where its own code lives, and the other three do the same. A failed workflow, an open Dependabot alert, a branch that has been waiting for two weeks or a service that still runs last week’s commit only show up if you go and look on GitHub.
That second place is where things get missed. In our own operation, 16 Dependabot updates were merged between 26 September and 9 October 2026, counted from the merge commits on the default branches: 2 in the week of 21 September (starting on the 26th), 7 in the week of 28 September and 7 in the week of 5 October up to Friday. Each of them was a point that needed a decision, and none of them would have appeared in a server dashboard.
What belongs on one page for a solo developer?
Everything that asks for an action, from both halves, and nothing that only describes. For a solo developer with a handful of repositories and one or two servers, that is a short list:
- Is every service up, and does it run the commit that is on main?
- Are there pending system updates, and does the firewall match what you saved?
- Did an Actions run fail on a default branch?
- Are there open security alerts, and which are runtime?
- Which branches or Dependabot updates are waiting?
The deployhandbook guide (updated 3 June 2026, checked 9 October 2026) describes the same reader as “three to ten apps on one or two VPSes” and places them between managed hosting and a full Prometheus stack. A page for that reader is useful when it is empty most of the time: on 9 October 2026 at 18:48, our own list showed 0 points across 17 repositories, 0 failed runs, 0 security alerts and 0 services behind main.
How does gitpuls combine both?
gitpuls is one option for this, not the only one: a self-hosted page that reads your GitHub account through the API and the state of your server from the host, and puts both into one list called Needs attention. It does not replace the tools above. It has no checks from outside and no metrics history, and because it runs on your own server, it cannot tell you that this server is down; for that, an outside check such as Uptime Kuma on a second machine is still the right tool.
What it adds is the repository half next to the server half: failed runs, security alerts, waiting branches and Dependabot updates, and whether each service runs what is on main. The repository is not public yet; the link on the start page follows when it is.
How this text was written
This article was drafted with an AI assistant from our own measurements and the sources linked above, which were checked on 9 October 2026. The numbers come from the method page; nothing was estimated.