#uptimekuma

Uptime Kuma Guide Self Hosted Monitoring and Status Pages

Why Choose Uptime Kuma

Uptime Kuma is the gold standard for self-hosted monitoring due to its user-friendly interface and robust feature set. It allows developers and home lab enthusiasts to track the health of their services in real-time.

Lightweight and easy to deploy via Docker

Supports HTTP, HTTPS, TCP, DNS, and more

Clean, responsive dashboard design

Key Features for Status Pages

One of the most powerful aspects of Uptime Kuma is its built-in status page generator. You can quickly create public or private pages to communicate service outages or maintenance windows to your team or clients.

Fully customizable branding and domains

Detailed incident history tracking

Granular permission settings for visibility

Getting Started with Self Hosting

Setting up your monitoring stack is straightforward, making it an ideal project for those new to self-hosting. By keeping your monitoring tools local, you maintain full control over your data and reduce reliance on third-party SaaS providers.

Simple one-line Docker installation

Integration with notifications like Discord, Slack, and Telegram

Flexible maintenance scheduling options

In this video, I explore how to set up Uptime Kuma on a Free VPS using Docker Compose to create a robust, 24/7 monitoring solution for your home lab or AI applications. I dive into the practical logic of utilising free-tier cloud resources to ensure your services stay online without adding to your monthly overhead.

The discussion covers the end-to-end deployment of a modern monitoring stack. I walk through my docker-compose.yaml configuration, which integrates Uptime Kuma for service availability alerts, Caddy for automatic SSL encryption, and the Beszel Agent for lightweight host metrics.

Practical Tips: Best practices for managing your monitoring environment via the terminal and keeping your containers up to date.

Whether you’re looking to monitor a complex AI workflow or just want a reliable status page for your personal projects, this setup provides a professional-grade solution at zero cost, and that includes running from a free VPS server.

For those using a self-hosted Alby Hub that hosts their Lightning Network Wallet to send/receive sats on the Nostr network, it is crucial that the connected wallet stays online. If not, the user cannot make or receive any sats.

I’ve noticed twice already that my wallet was offline, only about a day later. It seems that whenever my server has been rebooted, or the Alby Hub container is restarted after an update, that the Alby Hub requires a login again just to reactivate the wallet connection. All you have to do is go to the URL for your Alby Hub and type in that password, then everything is active again.

My problem though was, I was using my own self-hosted Uptime Kuma to alert me if my Alby Hub was offline. But if the container was restarted the Alby Hub page showed as online, and this alert only worked if the whole server was down or the container did not restart. It did nothing for Alby Hub being online, but not logged in.

I did determine earlier on that the indicator that showed if the Alby Hub wallet was online and logged in, would change the balance attribute to show either the sats balance as a number (logged in), or it changed the balance value to null if it was not logged in. If you have activated your access token on the Get Alby site at https://getalby.com/developer/access_tokens/new for balance:read, you can easliy run the following command from the terminal to read that data: curl https://api.getalby.com/balance -H "Authorization: Bearer access_code" where you replace access_code with your own access code. This will return some JSON code, and you will see a value for balance that either shows your actual sats balance, or it will show null.

So my multi-hour challenge today was to try to get Uptime Kuma to read that balance and if it was a value above 0 then consider the wallet online, but if it showed a null value, then send an alert to say it is offline.

My struggle was to get the returned value correctly evaluated in Uptime Kuma’s rather simplistic JSON evaluation field. The null value was also throwing out issues as you can’t use the number() function to convert a null value (it gave an error) and this was obscuring the logic I was trying to test.

In the end, the parts of it that worked in Uptime Kuma were (see post’s featured image):

Monitor Type: HTTP(s) - Json Query

URL: https://api.getalby.com/balance

HTTP Method: GET

HTTP Body Encoding: JSON

HTTP Body: {"balance": "application/json"} — this gets the value of balance

HTTP Headers: {"Authorization": "Bearer access_code"} – this is used to authorise access to query the balance value

Json query: balance != null ? 1 : 0 — checks if balance is not null, and if not then return 1, but if balance is null then return 0

Expected value: 1 — balance is expected to be 1 if all is fine