Guide · Uptime Kuma

How to put an Uptime Kuma status page on a TV or wall display

Uptime Kuma is the self-hosted monitor everyone runs, and its status pages are made for a wall: no login, automatic updates, groups, incidents, dark theme. This guide builds a page for a TV, sizes it for the distance, makes it private without touching Uptime Kuma, shows how the live dashboard can go on a screen too, and keeps a Raspberry Pi on it.

Updated 2026-09-089 minute readApplies to Uptime Kuma 1.23 and 2.x, checked against 2.5.3

Status page or dashboard: which one goes on the wall?

Uptime Kuma has two faces. The dashboard is where you log in and manage monitors; it needs the admin account and updates live over a WebSocket. A status page is the public view you compose from those monitors: a title, groups, heartbeat bars, incidents, and no login at all. For a screen, the status page is almost always the right one, and it is what the first three steps build. The dashboard route is covered further down for teams that want every heartbeat in real time.

Before you start

A running Uptime Kuma with monitors you want on the wall.
Its admin login.
For step 3 and the dashboard route: a reverse proxy such as Caddy or nginx in front of it.
A supported Raspberry Pi and a free DisplayOps account for the last part.

When you are done

A dark, TV-sized status page at its own URL that updates itself.
Optionally a password on it that only your screens know.
Optionally the live dashboard on a NOC screen.
A screen that reloads, recovers and reports back by itself.

View	URL	Login	Updates	Best for	Caveat
Status page	`/status/<slug>`	None; public by default	Polls every 5 minutes by default; any interval from 5 seconds in Uptime Kuma 2.0	Wall screens, lobbies, customers. Groups, incidents, your logo, dark theme.	No built-in password; make it private at your reverse proxy (step 3).
Dashboard	`/dashboard`	Always; there is one admin account and no viewer role	Live over a WebSocket	A NOC screen that wants every heartbeat bar and response time as it happens.	Needs the Disable Auth option plus basic auth at the proxy; the screen then has admin rights.

Step 1Build a status page for the wall

Make a page specifically for the screen, even if you already have a customer-facing one. The wall page can show internal monitors, tags and certificate expiry that customers should not see.

Create the page
Log in, open Status Pages in the top bar and click New Status Page. Give it a Title such as NOC wall and a Slug such as wall, then Next. The slug becomes the address:
https://status.example.com/status/wall
Add groups and monitors
The page opens in edit mode with a sidebar. Click Add Group for each block you want, for example Customer-facing and Internal, then Add a monitor inside each group. Drag to reorder.
Write the basics
In the sidebar fill in Description (one line, shown under the title) and Footer Text (who to call). Upload a logo if you like. Click Save.
Open the slug URL in a private window: the page loads with no login and shows the groups you built.
Optional: give it its own hostname or make it the front page
Under Domain Names in the sidebar add status.example.com and point that name at your proxy; Uptime Kuma serves the matching page at the bare hostname, as long as the proxy forwards the Host header. Or set SettingsGeneralEntry Page to this status page, which makes it the root of the instance.

Incidents

In edit mode the Create Incident button pins a banner with a title, a description and a style (info, warning, danger, primary) to the top of the page until you unpin it. It shows on the wall within one refresh interval, which makes the status page a simple broadcast channel for the team.

Step 2Tune it for a TV

The default status page is a centred column with laptop-sized text. Three settings fix that for a screen three metres away.

Dark theme and a faster refresh
In the page's sidebar set Theme to Dark. Set Refresh Interval to 30 seconds (Uptime Kuma 2.0 and newer); the page fetches new heartbeats in place without reloading.
Bigger text with Custom CSS
The page is built with rem units, so raising the root font size scales everything. Paste this into Custom CSS, save, and adjust the number until the heartbeat bars fill the width:
Custom CSS
```
/* Custom CSS on the status page: everything scales with the root font size */
html { font-size: 22px; }
.container { max-width: none; padding: 2rem 3rem; }
```
Decide what the wall shows
Show Tags on if tags carry the site or team name. Show Certificate Expiry on for a NOC, off for a lobby. Show Powered By off. Keep the number of monitors to what fits without scrolling; a second page and a slideshow beat a scrollbar.
The page fills a 1080p screen, dark, with monitor names readable from across the room.

Setting	What it does
Refresh Interval	Seconds between updates of the status page, minimum 5, default 300. Uptime Kuma 2.0 and newer; older versions refresh every 5 minutes and cannot be changed.
Theme	Auto, Light or Dark. Choose Dark for a TV.
Show Tags	Shows each monitor's tags next to its name. Useful for "site A / site B" on one page.
Show Certificate Expiry	Adds the days left on each HTTPS certificate. Good on a NOC wall, noise in a lobby.
Show Powered By	The "Powered by Uptime Kuma" footer. Turn it off for a cleaner wall.
Footer Text	Free text under the monitors, for example who to call.
Custom CSS	Any CSS, applied to this page only. This is where TV-sized text comes from.
Domain Names	Serve this page at its own hostname, for example status.example.com, when the proxy forwards the Host header.
Entry Page (Settings → General)	Makes a status page the front page of the whole instance, so the screen can use the bare hostname.

Step 3Make the page private, without touching Uptime Kuma

Status pages have no password of their own. Whoever can reach the URL can see it, which is fine for a customer page and not for an internal one. The fix lives one layer up: HTTP basic auth on the hostname at your reverse proxy. DisplayOps stores the username and password on the content item and the screen answers the prompt itself, for the page, its data requests and its icons, so nothing sits in the URL.

Add basic auth for the whole hostname

The status page calls /api/status-page/… for its data and /upload/… for icons, so protect every path rather than just /status. Admins type the password once in their browser and then log in as usual.

Caddyfile (caddy hash-password generates the hash)

status.example.com {
  # every path: the status page, its API, uploaded icons and the admin login
  basic_auth {
    lobby-tv $2a$14$Yu3…hashed-bcrypt-password…
  }
  reverse_proxy uptime-kuma:3001
}

nginx (htpasswd -B -c /etc/nginx/screens.htpasswd lobby-tv)

server {
  server_name status.example.com;
  location / {
    auth_basic           "Screens";
    auth_basic_user_file /etc/nginx/screens.htpasswd;
    proxy_pass           http://uptime-kuma:3001;
    proxy_http_version   1.1;
    proxy_set_header     Upgrade $http_upgrade;
    proxy_set_header     Connection "upgrade";
    proxy_set_header     Host $host;
  }
}

Uptime Kuma must not be reachable except through the proxy: bind it to localhost or keep it on the Docker network. Serve the proxy over HTTPS; basic auth on plain HTTP is readable on the wire.

Check it
In a private window the status page asks for a username and password, then loads completely, icons included.
Store the credential in DisplayOps
When you add the URL as content (below), tick The page asks for a username and password (HTTP authentication) and enter the proxy user. The HTTP authentication guide explains what happens under the hood.

Tip

Badges (/api/badge/…) and any customer-facing status page on the same hostname end up behind the password too. Give the public page its own hostname through Domain Names and leave that hostname open at the proxy.

The live dashboard on a screen

Some NOCs want the dashboard itself: every monitor with its heartbeat bar and response time, updating the moment a check runs. Uptime Kuma has one admin account and no read-only role, so a screen cannot have a login of its own. The supported way around that is the Disable Auth option under SettingsSecurity, which Uptime Kuma provides for installs "where you intend to implement third-party authentication". Your reverse proxy's basic auth is that third party.

Put basic auth on the whole hostname first
Exactly as in step 3, and make doubly sure Uptime Kuma's own port is not reachable from anywhere but the proxy. After the next step, anyone who reaches Uptime Kuma directly has full admin rights.
Disable the built-in login
SettingsSecurityDisable Auth. Uptime Kuma asks for your current password, warns Please use this option carefully! and confirms with I understand, please disable. From now on the proxy prompt is the only login; Enable Auth on the same page turns the built-in login back on.
Give the screen the dashboard URL
Add https://status.example.com/dashboard as website content with the proxy credential. The monitor list loads and updates live: Uptime Kuma opens a WebSocket for the dashboard, and Chromium sends the credential it already used for the page on that handshake as well, which we verified with the DisplayOps player.
Heartbeat bars advance on the wall as checks run, without the page reloading.

Careful

With auth disabled, the dashboard is not read-only. Whoever knows the proxy password, or reaches Uptime Kuma past the proxy, can add, pause and delete monitors. Use one long random password per screen, keep Uptime Kuma bound to the proxy, and prefer the status page unless you need the live view.

Put it on the screen and keep it there

A Raspberry Pi and a browser will show the page once. The failures come later: the browser leaks memory for a week, the TV sleeps, the Pi loses power, the proxy password rotates. DisplayOps exists for that part. The steps assume a supported Raspberry Pi and a free account.

Flash and pair
Write the DisplayOps image, plug the Pi into the TV and the network, and enter the pairing code shown on screen under DisplaysPair in the portal.
Add the status page as content
Content+ New content, type Website, URL https://status.example.com/status/wall. If you did step 3, tick the HTTP authentication option and enter the proxy username and password. Save.
Set a reload interval
On the display, SettingsAuto refresh: Every hour. The page already fetches new data on its own interval; the reload only clears browser memory and picks up CSS or layout edits.
Assign it and check
Open the display or a group and choose the content. The screen switches within seconds.
Take a screenshot from the display page: dark page, big text, all groups visible, no password box.
Add the human channel
Create a Message content item for incidents and push it to every screen when needed, then switch back. DisplayOps' own email notifications tell you when the screen itself goes offline, which the status page cannot report about itself.

Three screens are free on the Personal plan. The wallboard use case covers rotation and incident overrides for NOC screens in more detail.

Troubleshooting

"Not found" or a blank page at /status/wall. The slug is different, or the page was never saved. The bare /status address always means the page with the slug default.
The page shows old data. The refresh interval is long, or you are on Uptime Kuma 1.x where it is fixed at 5 minutes. Set Refresh Interval (2.0 and newer) or accept the delay; a DisplayOps auto refresh does not make Uptime Kuma check faster.
Behind basic auth the logo or icons are missing. The credential applies to one origin only. Icons come from /upload/… on the same host, so this happens when the page's assets are served from another hostname or when the protection covers only part of the site and confuses caching. Protect the whole hostname.
The custom hostname shows the wrong page. The proxy does not forward the Host header, so Uptime Kuma cannot match the domain name. Caddy forwards it by default; nginx needs proxy_set_header Host $host;.
The dashboard route says "loading" forever. The proxy is not passing the WebSocket upgrade (nginx needs the Upgrade and Connection headers), or Uptime Kuma still has auth enabled and is waiting for a login.
Text is too small or the page needs scrolling. Raise the root font size in Custom CSS, split the monitors over two pages, and rotate them with a DisplayOps slideshow.
The screen shows a password box. The content item has no credential ticked, or the agent is older than 0.2.2 (the Device card shows the version; screens update on their own).

Security checklist

A separate status page for the wall; customer pages keep only what customers should see.
Basic auth on the hostname for any page with internal monitors, HTTPS in front of it.
One proxy username per screen or group, with a long random password stored only on the content item.
Uptime Kuma reachable through the proxy only, especially if auth is disabled for the dashboard route.
Two-factor authentication on the admin account when the built-in login stays on.
Rotate the proxy password when a screen is retired, then update the content item and restart the player.

Uptime Kuma on a TV: questions we get

Can I password-protect an Uptime Kuma status page?

Not inside Uptime Kuma; status pages are public by design and a password option is a long-standing feature request. Put basic auth on the hostname at your reverse proxy instead, and let DisplayOps answer it on the screen. The page, its data and its icons all come from the same host, so one rule covers everything.

How often does the status page update?

Every 300 seconds by default. Since Uptime Kuma 2.0 each status page has a Refresh Interval setting with a minimum of 5 seconds. Older versions poll every 5 minutes and cannot be changed. The page updates in place; it does not reload.

Is there a read-only user for the dashboard?

No. Uptime Kuma has a single admin login, optionally with two-factor authentication. For a screen you either use a status page, or you disable the built-in login and rely on your reverse proxy's authentication, which is what the Disable Auth option is for.

Does the live dashboard work behind basic auth?

Yes. We tested the shape: once the DisplayOps screen has answered the challenge for the page, Chromium sends the same credential on the dashboard's API calls and on the WebSocket handshake that Uptime Kuma uses, so the monitor list updates live.

Can one screen rotate several status pages?

Yes. Make one content item per page and put them in a DisplayOps slideshow with a duration each, or give each page its own screen and manage them as a group.

Which Uptime Kuma versions does this apply to?

Status pages, custom CSS, custom domains and the Disable Auth option exist in 1.x and 2.x. The per-page Refresh Interval needs 2.0 (October 2025) or newer. This guide was checked against 2.5.3 (August 2026); a password option for status pages is still an open feature request there.

Put the status page on the wall and let it look after itself.

Three screens free. Flash, pair, paste the URL.

Start free with 3 screens What hardware do I need?

How to put an Uptime Kuma status page on a TV or wall display

Status page or dashboard: which one goes on the wall?

Before you start

When you are done

Step 1Build a status page for the wall

Create the page

Add groups and monitors

Write the basics

Optional: give it its own hostname or make it the front page

Step 2Tune it for a TV

Dark theme and a faster refresh

Bigger text with Custom CSS

Decide what the wall shows

Step 3Make the page private, without touching Uptime Kuma

Add basic auth for the whole hostname

Check it

Store the credential in DisplayOps

The live dashboard on a screen

Put basic auth on the whole hostname first

Disable the built-in login

Give the screen the dashboard URL

Put it on the screen and keep it there

Flash and pair

Add the status page as content

Set a reload interval

Assign it and check

Add the human channel

Troubleshooting

Security checklist

Uptime Kuma on a TV: questions we get

Related

Pages behind basic auth on a TV

Grafana dashboard on a TV

Your own dashboard page

Put the status page on the wall and let it look after itself.