Should Uptime Kuma run on the same server as my app?

No. Put it on a separate server so an application-server failure does not also remove the monitor. This still does not prove availability outside the provider or region you choose.

Do I need to make the Uptime Kuma dashboard public?

No. This guide publishes the private administrator dashboard behind HTTPS. A public status page is optional and should contain only the information you intend to share.

How do I test an Uptime Kuma alert safely?

Use a disposable monitor and a temporary target that returns an error. Confirm both the down and recovery notifications. Do not take down a production site just to test the notification path.

← All guidesSite Operations

Monitor a Site From a Separate Server With Uptime Kuma

August 31, 2026

Run Uptime Kuma on a separate Linux server, check a site over HTTPS, and prove the alert reaches you before an outage does.

Companion GitHub repositoryCompanion Uptime Kuma monitoring configurationTylorMayfield/uptime-kuma-droplet-monitorView on GitHub

Decide what this monitor can prove

Uptime Kuma can tell you whether its own server can reach a URL, port, certificate, or other configured target. That is useful. It is not proof that every user can reach your service, and it is not a replacement for application logs or a real incident plan.

Put the monitor on a different server from the site it checks. If the application Droplet crashes, fills its disk, or loses its network path, the monitor must still have a chance to send the alert. A second Droplet in the same provider is still one provider, so this guide improves separation from the app rather than claiming independent regional or provider-level coverage.

A DNS name for the private dashboard, such as status-admin.example.com.
A second Linux Droplet with an SSH key. Do not reuse the application server.
One URL on the target site that is safe to request without creating data or sending email.
One notification destination you can receive during the test.

Create and restrict the monitor server

Create a Linux Droplet for the monitor. Choose a region intentionally. Close proximity to the application reduces the chance that normal latency looks like an outage, while a different region can reveal more network failures. The right choice depends on what you want the check to mean, so write it down.

In DigitalOcean, create a Droplet with an SSH key. Name it for its role, such as uptime-kuma-monitor, rather than after the site it checks.
Create a Cloud Firewall and attach it only to this Droplet. Allow TCP 80 and 443 from the internet for HTTPS certificate issuance and dashboard access. Allow TCP 22 only from your current administrator address or VPN range.
Create an A or AAAA record for the dashboard name that points to the monitor Droplet. Wait for it to resolve before starting Caddy, because Caddy uses the name to obtain a public certificate.
Do not open Uptime Kuma's own port 3001 in the firewall. The companion Compose file keeps it on the internal Docker network and lets Caddy be the only public listener.

Start Uptime Kuma behind HTTPS

The companion repository keeps the configuration short on purpose. Uptime Kuma stores its state under ./data, while Caddy owns ports 80 and 443 and proxies to the Uptime Kuma container. The setup uses Uptime Kuma's maintained major-version image tag. Review the project's update notes before changing it.

Uptime Kuma documents that its data must live on a local directory or volume, not NFS. Keep the data on the monitor Droplet's local disk and include it in your server backup plan. The monitor should be boring enough that you can rebuild it, but its notification settings and monitor history are still useful data.

monitor-droplet8 steps

Before continuing: This starts public HTTPS services on the monitor Droplet. Confirm the DNS record and firewall rules before running it.

git clone https://github.com/TylorMayfield/uptime-kuma-droplet-monitor.git

Open the directorymonitor-droplet
```
cd uptime-kuma-droplet-monitor
```
Create the environment filemonitor-droplet
```
cp .env.example .env
```
Set the DNS nameServer file editor
```
nano .env
```

chmod 700 scripts/preflight.sh scripts/check-dashboard.sh

Run the preflightmonitor-droplet
```
./scripts/preflight.sh
```
Start the servicesmonitor-droplet
```
docker compose up -d
```
Check the dashboardmonitor-droplet
```
./scripts/check-dashboard.sh
```

Check the first response

Expected result: The dashboard is available over HTTPS, the down notification arrives after the controlled failure, and the recovery notification arrives when the target succeeds again.
Stop if: Stop if the monitor runs on the application server, port 3001 is public, the dashboard has no administrator account, DNS does not resolve to the monitor, or the notification test does not arrive.
Next step: Record the alert and recovery times, then add the production health check only after its URL and expected response are known.

Create one monitor and one notification before adding more

Open https://KUMA_DOMAIN and create the first administrator account. Treat it as a private operations dashboard. Do not make it a public status page by accident. A public status page is a separate choice for people who need to check your service, and it can expose service names and outage history.

In the dashboard, add a notification method you can test. Then add an HTTP(s) monitor for a harmless health URL, set its expected status code, and attach the notification. Start with one monitor. A dashboard full of checks that nobody has tested is wallpaper.

Send Uptime Kuma's notification test and confirm it reaches the intended person or channel.
Create an HTTP(s) monitor for a health URL that returns a predictable success response without changing application state.
Set a timeout and retry behavior that match the service. Do not choose a tiny timeout just to make the dashboard look busy.
Give the monitor a name that says what failed, such as Website HTTPS health check, rather than a vague name such as Production.

Prove an alert and recovery without taking down production

Do not call monitoring complete because the dashboard is green. Create a temporary route or disposable test target that returns an error, point a temporary monitor at it, and wait for the down notification. Then make the target succeed again and confirm the recovery notification arrives. Record the time between failure and alert.

Do not stop the real site to test this guide. A controlled target gives you the same proof without creating an avoidable incident. If you cannot make a harmless failing target, test against a disposable service first and say clearly that the production alert path remains unproven.

Before continuing: This restarts the monitoring dashboard. Run it only after a working deployment exists.

cd uptime-kuma-droplet-monitor
docker compose restart
./scripts/check-dashboard.sh

Keep the signal useful

Review monitors after the first false alert. If a transient failure is common and harmless, change the retry or timeout after you understand it. Do not silence a monitor because it caught an inconvenient problem. Route alerts to people who can act on them, and remove destinations when responsibilities change.

Update Uptime Kuma deliberately. Back up its local data, read the upstream update notes, pull the image, recreate the services, and recheck one dashboard login, one monitor, and one notification. An unattended monitor that broke during its own update is a familiar bad joke.