A Second Uptime Kuma: When the Monitor Host Is the Thing That Dies

Your uptime board is green for weeks. Then the mini PC that runs Uptime Kuma loses power, locks up, or fills its disk, and the silence is perfect. No red tiles. No ntfy. No proof. The monitor host became the outage, and a single Kuma cannot testify against itself.

A second Uptime Kuma—or any second vantage point—is how solo operators close that hole without pretending they run a NOC. This is about when the second instance is worth the bother, where to put it, and how to avoid paging yourself twice for every real blip.

The failure mode you are actually buying insurance against

Kuma on the same UPS, same switch, and same ISP path as the rest of the lab shares fate with the lab. That is fine for “is Immich answering on the LAN?” It is useless for “is the house dark?” and weak for “did the whole rack reboot?”

You want a checker that fails when the primary path fails. That usually means a different power domain, a different network path, or both. A container on the same Docker host is not a second Kuma. It is a second process with the same destiny.

What “a second Kuma” can mean

Second instance on a cheap VPS. Watches public hostnames and a few things you intentionally expose or reach through a stable tunnel endpoint. Good for “is my blog up?” and “is the house VPN concentrator answering?” Bad for raw RFC1918 URLs unless you build a path.

Second instance at a friend’s house or a second physical site. Strong when you already have mesh connectivity. Fragile when friendship uptime is worse than your own.

Second instance on a travel router or always-on phone hotspot path. Niche, but real for people who already keep a small offsite foot in the network.

Not-Kuma second opinion. Gatus, a cron curl to Healthchecks, or a cloud synthetic check. The brand matters less than independence. If your brain already lives in Kuma, a second Kuma keeps muscle memory. If you hate another SQLite UI, use a tiny config-based checker offsite.

When one Kuma is still enough

Skip the second instance when:

• You only care about services while you are home on the LAN.
• Your “monitoring host” is already a VPS and the lab is what it watches—not the other way around.
• You would not act on an alert that says the house is down until you are back anyway.
• You have not fixed notification reliability on the first instance yet.

A second dashboard does not fix ntfy running on the same dead NAS. Move notifiers off the fate you are measuring before you clone the UI.

Design rules that keep you sane

Watch the watcher. Primary Kuma should have a monitor for the secondary’s UI or a push heartbeat from the secondary. Secondary should watch the primary. Avoid a silent mutual death without a third signal—email from the VPS provider, a simple external cron, or a human who notices the house Wi-Fi SSID missing when they get home is better than nothing.

Split the monitor list. Do not clone every LAN check to the VPS. The VPS should watch public endpoints, tunnel targets, and maybe one “canary” that proves the mesh path. Primary Kuma keeps the ugly internal names.

Deduplicate alerts. Same outage, two Kumas, two channels is how you disable notifications forever. Tag alerts with site=home and site=vps, or send secondary alerts to a lower-priority channel. Page hard only when both agree, or when the watcher itself is dark.

Different credentials, same discipline. Separate admin passwords. Separate backup of each SQLite volume. Document which instance is authoritative for which services.

Topology patterns that work in real apartments

Home primary, VPS secondary. Home watches LAN and Tailscale services. VPS watches https public sites and a health URL published only for that purpose. If home dies, VPS pages. If VPS dies, home pages. If the internet dies, you may get both—or neither, depending on paths. Accept that ambiguity.

VPS primary, home secondary. Better when most of what you sell or publish lives in the cloud and the lab is a hobby. Home secondary is then a courtesy for local services.

Mesh-aware checks. Secondary reaches home services over Tailscale. When the tailnet path dies, you learn about mesh or exit-path failure—not necessarily about Immich’s container health. Label monitors so you do not misread a mesh failure as an app failure.

Operational cost people underestimate

Two instances means two upgrade habits, two certificate stories if you expose UIs, two backup jobs, and twice the chance to leave a maintenance window on only one side. Budget thirty minutes a month or the second Kuma becomes folklore.

Also budget honesty about secrets. Notification tokens on a VPS are higher risk than tokens on a machine that never leaves your VLAN. Use scoped tokens and a channel that is not also your bank OTP device.

Alert semantics: “home dark” versus “app down”

Train yourself to read the second instance as a different question. When home Kuma says Immich is down, you debug Immich. When VPS Kuma says the home canary is down, you debug power, ISP, firewall, or Tailscale before you SSH into a container that may not exist on the network you still have.

Write monitor names that encode the question: canary: home kuma via tailscale is clearer than kuma. Incident messages should not say “Immich down” when the only evidence is that a tunnel path failed. Over-precise names save you from under-precise panic.

If both instances watch the same public URL, expect correlated alerts during real outages. That correlation is useful confirmation—once. The second ping should be softer: a Discord message instead of a phone buzz, or a delay so the primary has time to speak first. Confirmation is not the same as a double page.

Storage, backups, and reclaiming a dead primary

When the primary host dies, you will want history. That does not mean the secondary must store years of LAN latency charts. It means you should be able to answer “when did the house go quiet?” from the secondary’s canary timeline. Keep retention modest on the VPS; keep richer history at home if you care about it, and accept that richer history dies with the host unless you replicate the database—which most people will not.

After a primary death, rebuild from Compose and a monitored list in git if you have one. If your monitor list only lived in the dead SQLite file, the second Kuma will not resurrect your LAN checks. Export or document the primary’s monitor set the same week you deploy the secondary. Insurance that forgets the policy details is still theater.

A minimal build that is still real

1. Keep existing Kuma at home for LAN monitors.
2. Deploy a tiny Kuma (or Gatus) on a $5 VPS.
3. On the VPS, monitor: your public site, any SaaS you owe people, and the home Kuma URL over Tailscale or a dedicated canary.
4. On home Kuma, monitor the VPS Kuma URL.
5. Send VPS alerts to a channel you will not mute after the first double page; tune until duplicates are rare.
6. Once a quarter, pull the plug on the home monitor host on purpose and confirm the VPS notices.

That last step is the product. Without a drill, you have architecture cosplay.

Alternatives if you refuse a second dashboard

External synthetic checks from a vendor. A cron on a free tier CI that curls and pages. A friend with a reciprocal “ping my URL” agreement. Healthchecks with a dead man’s switch heartbeaten from a different machine than the one that runs your apps. All of these can beat a decorative second Kuma.

What does not count: another Compose service on the same NUC, a Raspberry Pi on the same power strip, or a status page that is also hosted on the dead host.

Decision guide

Add a second vantage point when silence from the monitor host would be indistinguishable from “everything is fine,” and when you would actually travel, reboot, or page someone in response.

Keep a single Kuma when your monitoring host is already offsite relative to what it watches, or when you only need LAN truth while you are home.

If you are still unsure, run the plug-pull drill once on a weekend afternoon. If the only symptom is that your phone stays quiet, you have your answer. If the VPS or friend-site checker lights up within a minute, you may only need better documentation—not a third dashboard. Write down what fired and what did not; that scrap of paper is more valuable than another theme for the UI. Keep it with the host recovery notes on the shelf by the UPS where you will actually look.

The second Uptime Kuma is not about prettier charts. It is about refusing to let the umpire die without a witness. If your current board cannot complain about its own absence, you do not have uptime monitoring—you have a mood lamp that likes HTTP.