Short answer: no. Uptime Kuma is single-user by design. There is one admin account, no roles, and no way to give a client a login that shows only their services. You can create a separate branded status page per client, but every person who can log in sees and can edit every client’s monitors. If you run monitoring for multiple clients and each one needs their own scoped access, Uptime Kuma cannot do it today.
This is the most common thing agencies and MSPs get wrong about Uptime Kuma, so it’s worth being precise about what it can and can’t do.
What Uptime Kuma can do for multiple clients
Uptime Kuma (82k+ GitHub stars, the default self-hosted uptime tool) genuinely does some of what an agency needs:
- Multiple status pages. You can create a separate status page per client, each with its own logo, theme, and custom domain via a reverse proxy. Unlimited, free.
- Grouping. You can organize monitors into groups on a status page.
- Notifications. 90+ notification integrations.
On the public-facing side — the page your client’s users see — Uptime Kuma is fine.
What it cannot do: separate logins per client
The gap is on the authenticated side. Uptime Kuma has:
- One user account. The admin. There is no user management screen.
- No roles or permissions (RBAC). There is no “read-only” user, no “this user sees only Client A” scoping.
- No per-client login. You cannot hand a client credentials that open onto their monitors and nothing else.
This is not a configuration you’re missing. Multi-user support has been the single most-requested feature for years — tracked in issue #1584 and issue #5862, both still open. The maintainer has acknowledged it; it is a large architectural change, not a setting.
So the practical situation for an agency: anyone you give dashboard access to can modify or delete any client’s monitors. Your client’s “isolation” is cosmetic — it’s a separate public page, not an access boundary.
What about Gatus?
Same story, slightly different shape. Gatus supports a single basic-auth user or OIDC, but not multiple scoped users — multi-user basic auth is an open request (#1306). Its remote-instance aggregation is flagged experimental. For per-client authenticated access, Gatus has the same gap.
The real options if you need per-client logins
If “each client gets their own login to their own status page” is a hard requirement, here’s the honest landscape as of 2026:
| Tool | Per-client login? | Notes |
|---|---|---|
| Uptime Kuma | No | Single user, no RBAC |
| Gatus | No | Single basic-auth user |
| UptimeRobot | No — shared page password only | A page password is not a login: no per-client identity, no revoking one client without changing everyone’s password |
| Better Stack | No — shared page password only | Same limitation |
| Atlassian Statuspage | Yes (real per-viewer auth) | But it does no monitoring — you pay a monitoring vendor separately. Private/audience pages start around $79–$300/mo |
| Site24x7 MSP | Yes (RBAC per customer) | Genuine multi-tenancy, from ~$248/mo at agency scale |
| Warden | Yes (status_viewer role) | Open-source; a client login that shows only their status page. Self-host it free or have it run for you |
The pattern worth noticing: the free self-hosted tools can’t give a client a login at all, and most of the cheap SaaS tools give you a shared page password and call it access. A shared password has no client identity, can’t be revoked for one client, and leaves no record of who looked. Only a few tools treat “this person sees only their own services” as a real authenticated concept.
Bottom line
- Uptime Kuma multi-tenant, with a login per client: not possible today. Single user, no RBAC, tracked in open issues #1584 and #5862.
- You can run separate branded status pages per client — but not scoped logins.
- If per-client logins matter, you need a tool that models it: Atlassian Statuspage (pages only), Site24x7 MSP (paid), or an open-source option like Warden that ships a client-only role.
If you just need public status pages and you’re the only operator, Uptime Kuma is excellent and free. The moment a client needs their own account, it’s the wrong tool — and no amount of configuration changes that.