Uptime Kuma can publish multiple status pages, but its standard dashboard does not provide separate, scoped client accounts. If you searched for “Uptime Kuma multiple users,” first decide whether you need public visibility, private viewing or independent administration. Those are different requirements.
Reviewed against Uptime Kuma 2.5.5 and Warden v0.9.0 on October 7, 2026. Project Helena maintains Warden.
Option 1: separate public status pages
Kuma supports multiple status pages and mapping pages to specific domains. Use that when clients only need to see the published health of their services. Your operations team keeps dashboard access; each client receives their page URL.
A page’s branding and monitor selection do not create an authenticated tenant. Decide which service names and incident details may be public before adding them. A reverse proxy can restrict access to a page, but it does not add client roles inside Kuma.
Option 2: a separate instance per client
Separate instances give each client their own administrative boundary and allow different upgrades or notification configurations. They also multiply backups, credentials, deployment work and failure points. Put those operating costs into your decision even when the software has no license fee.
This can be the right answer if clients need to own their monitor configuration. Keep their databases and secrets separate. Do not present several status pages in one shared dashboard as equivalent isolation.
Option 3: Warden for scoped viewing
Warden has four roles. The relevant one for this use case is status viewer: an individual account associated with one status page. A client can view that page without receiving permission to edit monitors or administer the instance.
| Requirement | Public page | Separate instances | Warden status viewer |
|---|---|---|---|
| Share service health | Yes | Yes | Yes |
| Individual client login | Not by itself | Instance-specific | Yes |
| Client administers only their monitors | No | Yes | No; viewing only |
| Revoke one viewer’s account | Not with a public URL | Depends on the instance | Yes |
| Separate runtime/database | No | Yes | No |
The last two rows matter. A status-viewer account is useful access control within a shared service. It is not a separate process, database or complete tenant administration model. Warden’s notification channels are also global, so do not promise client-specific alert routing from this setup.
Verify the boundary before inviting a client
Install Warden with one test endpoint, then use the status-page guide and roles documentation:
- Create a group and status page containing only the intended services.
- Create a status-viewer account assigned to that page.
- Open a separate browser session as that user.
- Check that the intended page works and unrelated administration is unavailable.
- Revoke the account and confirm that its authenticated access ends.
Keep public and private access decisions explicit: revoking an account does not make a publicly accessible page private. Test the page while signed out too.
If public pages already solve your problem, keep the simpler setup. If scoped logins are the missing requirement, compare Warden and Kuma and evaluate with one client before moving everyone.