Uptime Kuma Status Pages vs a Tailscale-Only Dashboard: When a Public Page Leaks Your Hostnames

Uptime Kuma’s status pages feel like a grown-up move. You get a clean public URL, incident history, and a way to tell family—or the three friends who use your Jellyfin—that the outage is real and you already know. The problem is what that page silently advertises: service names, hostnames, uptime patterns, and sometimes enough topology to sketch your lab from a coffee shop.

A Tailscale-only dashboard solves a different social problem. Only devices on the tailnet see the green tiles. Guests without an invite see nothing. That is safer by default and worse when someone outside the mesh needs a truthful “we’re down” signal without joining your network.

This is the trade-off between a public status surface and a private ops console—not a feature shootout between products.

What a status page actually publishes

Even a minimal Kuma status page tends to leak more than “something is wrong.” Monitor names often mirror internal DNS: nas.home.arpa, immich.lan, proxmox-a, zigbee-coordinator. Group names reveal roles. Latency charts reveal when you sleep and when deploys happen. Incident messages written in a hurry mention versions, IPs, and “failing over to the spare Pi.”

None of that is catastrophic by itself. Combined with a domain you already use elsewhere, it becomes a map. Attackers do not need root on day one; they need a list of interesting doors and a sense of which ones matter to you.

Public status pages also teach timing. A service that is “up” only between 18:00 and 23:00 local time is a hobby box that is powered down—or a PC that is not always a server. That is useful intelligence for anyone who cares.

When a public Kuma status page is still worth it

Keep a public page when the audience is truly external and the naming is deliberate.

• You run a small community service and people need a place to look before they DM you.
• You sell a tiny SaaS and customers expect a status URL that is not behind your admin VPN.
• Household members refuse Tailscale and will otherwise call you during every blip.
• You are willing to rename monitors to bland public labels and keep real hostnames private.

The last bullet is the whole game. A public page named “Photos,” “Media,” and “Files” says less than “immich.internal,” “jellyfin-gpu,” and “nextcloud-db.” You can still alert yourself with detailed monitor names on the private dashboard while the status page shows curated aliases.

If you cannot commit to that curation, you do not want a public page. You want a private dashboard and a human message channel.

When Tailscale-only is the correct default

Most homelabs should start private. If the only consumers of uptime data are you, a partner on the same tailnet, and maybe a travel laptop, exposing a status page is theater with a side of reconnaissance.

Tailscale (or Headscale, or another mesh) gives you:

• Authentication that is already your admin boundary.
• No need to put Kuma’s UI or status app on a public reverse proxy.
• A natural place to keep ugly-but-useful monitor names.
• Fewer certificates and fewer “I exposed the wrong path” incidents.

The failure mode shifts. Instead of leaking hostnames, you risk locking yourself out of visibility when the mesh control path or your phone’s key is unhappy. That is a real risk—but it is a risk you already accepted by putting admin UIs on the tailnet in the first place.

Hybrid patterns that do not fool yourself

Private Kuma, public stub. Keep full Kuma on Tailscale. Publish a one-line static page or a separate minimal status app that only says “operational / degraded / outage” for one or two customer-facing products. Do not auto-publish every monitor.

Public page with boring names, private page with real ones. Kuma can drive a status page from a subset of monitors. Use that subset ruthlessly. The monitors that page you at 2 a.m. do not all need to be on the public list.

ntfy / Discord for humans, dashboard for you. Many “status page” requests are really “text me when Jellyfin dies.” A notification channel answers that without a directory of services on the open web.

External checker, private names. If you need an outside vantage point, run a second checker on a VPS that only knows public hostnames you already advertise—your blog, your SaaS apex—not your lab DNS.

Hostname hygiene checklist before you flip the switch

1. Read every monitor name as if you did not own the network. Would you hand that list to a stranger?
2. Strip internal TLDs, VLAN names, and hypervisor labels from anything public.
3. Remove monitors that exist only for your debugging ego.
4. Write incident templates that do not include IPs, package versions, or “failover to X.”
5. Put the status page on a hostname that does not also host admin panels.
6. Rate-limit and cache; you do not need crawlers refreshing your uptime every second.
7. Decide who can post incident updates. A compromised status account is still a trust hit.

If that list feels like work you will skip, keep the dashboard on Tailscale and stop optimizing for strangers.

Incidents people actually regret

A common pattern: someone enables a status page “just for family,” leaves monitor names equal to internal DNS, and later shares the URL in a Discord troubleshooting thread. The URL outlives the thread. Search engines may never rank it highly, but chat logs, screenshots, and link previews keep copies.

Another pattern: the status page sits on the same reverse proxy as the admin UI with a slightly different path. Path guessing and cookie scope mistakes turn “public read-only status” into “I hope I did not leave a session cookie on that host.” Separate the concerns. Different subdomain at minimum; different machine when you can spare one.

A third pattern: maintenance posts that are too helpful. “Migrating Immich off the old Ryzen box; Postgres dump running on 192.168.10.20.” That message is perfect for your private notes and terrible for a public incident banner. Keep a private runbook and a public sentence that says “media library restore in progress; ETA evening.”

The social layer people underestimate

Status pages set expectations. A public history of flaky weekend maintenance trains users to distrust you—or to ignore real outages. A private dashboard lets you be honest with yourself without performing reliability theater for an audience of twelve.

Conversely, hiding everything on Tailscale can make you the single bottleneck. When you are offline and the only status channel is “ask me,” you have built a human SPOF. For family media servers, a boring public page with two aliases can be kinder than radio silence—if the naming stays boring.

Match the surface to the relationship. Friends who already have Tailscale accounts should use the private UI. Parents who will never install a mesh client may need a page or a text. Paying users need something that is not your Discord #homelab channel.

Security notes without paranoia cosplay

A status page is not an open proxy into your lab. It is still a reconnaissance convenience. Pair it with the same discipline you use for any public site: minimal data, separate host if you can, no admin cookies on that domain, and no “click here to manage” links that hit the real Kuma UI.

Also remember that “private” is not “safe from everyone.” Tailscale ACLs that share the whole tailnet with a roommate’s laptop share the dashboard too. Hostname leakage can happen inside the mesh if you invite broadly. Scope who can reach the Kuma machine the same way you scope who can reach Proxmox.

If you use Funnel or another public publish feature for convenience, treat that as public internet, not as “basically private.” Convenience features erase the boundary your brain still thinks exists.

A quick decision table you can argue with

If your audience is only on the tailnet, do not build a public page to feel professional. Professionalism here is least surprise: the people who can break the lab can see the dashboard.

If your audience includes people who will never install a client, publish the smallest truthful surface you can stand behind for a year. Two aliases beat twenty honest hostnames.

If you are tempted to publish because a blog post said status pages are best practice, ask whether you have customers. Most homelabs have relatives, not SLAs. Relatives prefer a text that says “photos are down until dinner.” Customers prefer a URL. Pick the relationship you actually have.

Decision guide

Choose a public Uptime Kuma status page when outsiders need a deliberate, curated signal and you will maintain aliases that do not map 1:1 to internal DNS.

Choose a Tailscale-only dashboard when the operators are already on the mesh and a public directory of services would only help people who should not have it.

Choose a hybrid when you have one or two external promises and a long private list of lab checks—and you keep those lists from merging in a tired evening of “just expose it.”

The leak is usually not a zero-day. It is a monitor named after a hostname you never meant to publish. If you cannot rename it, do not publish it.