Self-Host Uptime Kuma with Greffon
A monitor tells you when things break, so it has to outlive the things it watches. Here is the honest setup for Uptime Kuma on a greffer, including the one place not to host it.
Uptime Kuma is a self-hosted watchdog: it pings your sites, services, and ports on a schedule, shows you a clean status page, and pings you when something stops answering. The appeal of running your own is the same as running your own anything. You are not paying a monitoring SaaS per check, and the data about what you run stays on a machine you own. Greffon takes the reverse-proxy and certificate work off your plate so the monitor comes up reachable over HTTPS from the first start.
Why own the monitor
Uptime Kuma covers the checks most people reach a paid tool for: HTTP and HTTPS endpoints, TCP ports, DNS records, ping, and keyword matching on a page. It keeps history, draws uptime percentages, and publishes a public or private status page you can point users at during an incident. It is light enough to sit comfortably on a modest greffer alongside whatever else you run.
The honest pitch is not that self-hosting makes monitoring more accurate. It is that you own the box, the history, and the notification config, instead of renting them. That trade comes with one real catch, covered below: a monitor that runs next to the things it watches cannot tell you when the whole machine goes dark.
Graft it from the catalog
On a greffer you do not hand-write a compose file or wire a reverse proxy. Pick Uptime Kuma from the catalog and graft it onto your greffer. Greffon issues the certificate and routes the app, so it comes up reachable over HTTPS without you assembling that plumbing by hand. On first load you create the admin account directly in the web UI, then start adding monitors.
Reach it and get alerts out
The dashboard and status page are plain HTTP apps, which is the easy case for external access. On the same network as your greffer it works the moment it starts. To reach it from anywhere else you have two honest options.
The simplest is tunnel mode: a greffer connects outbound to the manager's tunnel and serves its apps without opening a single inbound port, which is the answer for a box behind NAT or CGNAT with no public IP. If you would rather expose the greffer directly, port forwarding plus dynamic DNS still works. Either way the dashboard and status page stay reachable over HTTPS. Alerts are separate: Uptime Kuma sends notifications outbound to the channels you configure (email, Telegram, Slack, a generic webhook, and many more), so getting alerts out does not require any inbound exposure at all.
Where a watchdog should live
This is the tradeoff specific to a monitor, and it is worth stating plainly: a watchdog cannot report on the machine it is running on. If you host Uptime Kuma on the same greffer as the services it watches and that greffer loses power or its network, the monitor goes down with everything else and you get no alert about the outage that matters most.
Back up the config
All of your monitors, notification settings, status pages, and history live in Uptime Kuma's data directory on the greffer. Losing it means rebuilding every check and alert by hand. Greffon handles TLS and routing today, and native one-click backups are coming in M2. Until then, bring your own backup tool (restic or borgbackup are the usual choices), back up the Uptime Kuma data on a schedule, and store a copy off the greffer. The dataset is small, so this is cheap to do often.
Keep it always-on
A monitor that sleeps misses outages, so it needs to be up around the clock. Run it on an always-on greffer such as a small VPS, a mini-PC, or a free Oracle Cloud box, rather than a laptop that sleeps at night. The Oracle walkthrough is a good place to get an independent greffer running, which doubles as the separate machine a watchdog wants to live on.
