How to Self-Host an Internal Status Page for Your Tools

A self-hosted internal status page is a monitoring dashboard, usually Uptime Kuma running in Docker behind a reverse proxy, that checks your internal tools on a schedule and shows their status on a private page you control. Build one in an afternoon for the cost of a $5 VPS, instead of paying $29 to $1,499 a month for a SaaS tool built for customer-facing incident comms.¹

Here's the full build, and the tradeoffs worth knowing before you commit.

Why teams building internal tools also need a status page

More of your company's software isn't coming from IT anymore. It's coming from whoever on the ops team learned to spin up a script, a dashboard, or an AI agent. Shadow AI adoption alone has grown fast: 78% of AI users at work now bring their own tools outside IT approval, and shadow IT overall is estimated to account for 30-40% of large-enterprise IT spend.² That sprawl leaves a gap: nobody owns the answer to "is the internal reporting tool actually up right now," because it was never provisioned through the channels that come with monitoring built in.

Public status page tools like Atlassian Statuspage answer a different question for a different audience: telling paying customers about an outage during an incident. They're communication layers, not monitoring tools, priced and structured accordingly. Point that setup at your own admin dashboards and internal APIs, and the mismatch shows up fast, in cost and in missing features.

How much does Statuspage actually cost for an internal team?

Atlassian Statuspage's plans run from a $29/month Hobby tier up to a $1,499/month Enterprise tier for 25,000 subscribers.¹ Subscriber count means nothing to an internal team, but you pay for it anyway.

The real cost is what's gated behind higher tiers:

• Custom CSS requires the $99/month Startup plan.¹
• Custom HTML/JavaScript and white-labeling require the $399/month Business plan or above.¹³
• Private pages are a separate add-on, around $70/month, not bundled into any base tier.³
• SSO is another account-wide add-on, roughly $100/month.³

None of this includes monitoring. Statuspage is a manual display and communication layer; it doesn't detect outages on its own.³ One buyer comparison estimates that pairing it with separate monitoring and alerting tools (Pingdom, Opsgenie) adds another $150 to $300 a month, pushing a realistic startup-scale setup to about $249/month.⁴⁵ That's real money for something an internal team can run for the price of a small VPS.

Which self-hosted status page tool should you use?

Several open-source options exist, and they land in different places on maintenance burden and features.

• Cachet needs about 512MB of RAM and has no built-in private pages.
• Upptime and cState are static, GitHub-hosted, and also lack private-page auth.
• Gatus is remarkably light, running in as little as 64MB of RAM as a single Go binary, but it's monitoring-first with a thinner status UI.⁶
• OneUptime is the outlier: a full platform with SSO-gated private status pages, but it recommends at least 4GB of RAM, overkill for tracking a handful of internal tools.⁶
• Uptime Kuma sits in the middle and is the default pick for most teams. It has 90,700 GitHub stars and 8,300 forks, the most widely adopted tool in this category.⁷ It supports HTTP(s), TCP, DNS, ping, Docker container, and push-based monitoring, with checks as frequent as every 20 seconds and over 90 notification integrations.⁷ It doesn't ship per-user authenticated private pages out of the box, but for an internal tool, network-level privacy solves that problem more simply anyway (more on that below).

Step 1: Provision a small VPS or internal server

Uptime Kuma doesn't need much. A 1 vCPU, 1GB RAM VPS handles most small setups.⁸ It runs fine on a homelab box, a spare internal server, or the cheapest tier of any cloud provider. Keep it separate from the infrastructure hosting the tools you're monitoring. More on why in the last step.

Step 2: Deploy with Docker Compose

The official repo ships a straightforward Docker setup. The simplest path is one command:

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2

This exposes the dashboard on port 3001.⁷ If you don't want it reachable outside the host yet, bind it to localhost instead:

docker run -d --restart=always -p 127.0.0.1:3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2

That's the maintainers' own recommendation for limiting exposure before you've set up a proxy.⁷ For a production-style setup, pair a Docker Compose file with Nginx and Certbot. Third-party install guides document the pattern step by step.⁸

Step 3: Put it behind a reverse proxy with HTTPS

Uptime Kuma runs over WebSocket. Any reverse proxy in front of it, whether Nginx, Caddy, Traefik, HAProxy, or Nginx Proxy Manager, must forward the Upgrade and Connection headers or the dashboard and status page will fail to load correctly.⁹ This trips up more setups than it should. If your page loads but never updates, check those headers first.

One limitation worth planning around: Uptime Kuma can't serve a status page from a subdirectory like example.com/status. It needs a dedicated domain or subdomain.⁹ Budget for something like status.internal.yourcompany.com from the start.

How do you keep a self-hosted status page private?

Uptime Kuma doesn't offer per-user authenticated private status pages, and neither do the lighter alternatives (Cachet, Upptime, Gatus, cState).⁶ Only full platforms like OneUptime bake SSO into the status page itself.⁶

That's fine for an internal tool, because the right way to keep it private isn't app-level auth. It's network-level restriction:

• VPN or Tailscale, so the page is only reachable from devices already on your private network.
• Internal DNS, so the subdomain simply doesn't resolve outside your network.
• Cloudflare Tunnel plus Access, which puts an identity check in front of the tunnel without touching Uptime Kuma's own auth.
• Firewall rules on the VPS, allowing traffic only from known office or VPN IP ranges.

Any of these gets you a genuinely private page without waiting on app-level SSO that doesn't exist yet in the lighter tools.

Step 5: Add your internal tools as monitors

Once the dashboard is reachable, add a monitor for each internal service: your admin panel over HTTP, an internal API over TCP, a Docker container running a self-built agent, or a DNS record for a service that shouldn't ever resolve to the wrong host. Uptime Kuma supports all of these natively, plus push-based checks for services that report in themselves.⁷ Set check intervals based on how fast you need to know: a customer-facing internal tool might warrant checks every 20-30 seconds, while a batch job's health check can run every few minutes.

Step 6: Configure alerts and the public-facing status page

Wire up notifications so the right people hear about a problem before someone pings them on Slack asking why a dashboard is broken. Uptime Kuma's notification list covers Slack, email, Telegram, and over 90 other integrations.⁷ Then publish a status page grouped by tool or team, so a non-engineer can glance at it and know whether the CRM sync or the internal reporting service is the one that's down.

Step 7: Plan for the status page's own downtime

There's an obvious irony in a monitoring tool that goes down along with everything it's watching. A few habits prevent that:

1. Host it separately. Run the status page on different infrastructure from the tools it's monitoring, so one outage doesn't take both down together.
2. Back up the data volume. Uptime Kuma stores its state in SQLite. Back that volume up on a schedule, not just when you remember.
3. Keep it updated. Self-hosting means you own patching, so put Uptime Kuma version bumps on the same cadence as your other internal infrastructure.

This is the same discipline that applies to any self-hosted tool an internal team leans on, whether it's a monitoring dashboard or an AI agent workflow built in-house. If you're already tracking a growing list of self-built internal services, a tool like Remy can help you keep an inventory of what exists before you even get to monitoring it.

When should you move beyond a single self-hosted status page?

A single Uptime Kuma instance covers most internal-tool monitoring needs indefinitely. Move to something heavier when:

• You need external customer subscribers, not just an internal team, and want automated subscriber notifications rather than a shared internal link.
• Compliance or SSO requirements mean you need audited, per-user access control on the status page itself, which only full platforms like OneUptime currently support out of the box.⁶
• You need postmortem workflows, incident timelines, and structured retrospectives built into the same tool, rather than tracked separately in docs.
• Your team has outgrown VPN-based access control and needs finer-grained, app-level permissions than network isolation can provide.

Until one of those is true, the math stays lopsided: a $5 VPS and an afternoon of setup buys the same "is it up" clarity as a $29-$1,499/month SaaS tool, plus ownership of your own data and auth model instead of renting someone else's.¹⁸