Comparison

Uptime Kuma says down. Cloud says which layer.

Uptime Kuma is a good, free uptime monitor, and for plenty of setups it is enough. This page is about what changes when the things you monitor are Docker containers published on a tailnet.

Start 30-day trial Jump to the table

Same DockTail agent · one environment variable · runs next to Uptime Kuma without conflict

The same outage, twice

Down is where an uptime check stops.

Grafana gets OOM-killed at 14:22. Both tools notice within a minute. Here is what each one hands you.

What Uptime Kuma shows monitor: grafana
grafana Down
14:22:41 · connect ECONNREFUSED 172.18.0.4:3000
Accurate, and now the work starts: SSH in, docker ps, check the Tailscale admin console, is the box even up?
What DockTail Cloud shows incident #182 · grafana on prod-01
grafana container problem
  1. 14:22:07docker event die · exit 137 · oom killed
  2. 14:22:11local check refused · 172.18.0.4:3000
  3. 14:22:11tailnet advertised · approved — exposure is fine
  4. 14:22:11host up · mem 15.8 / 16 GB 
14:22:06 fatal: runtime: out of memory
Restart it with a memory limit. Do not touch the tailnet. The log line that says why is already attached.

Container

The process died. Cloud attaches the Docker event: exit code, OOM kill, failing healthcheck, restart loop, and a log tail captured at the moment it happened.

Exposure

The container answers, nobody can reach it. The Tailscale control plane says the service is awaiting approval, not advertised by this host, or gone. An uptime check on the tailnet FQDN cannot tell this from a crash.

Host

The box went silent. Heartbeats stop, and the tailnet confirms whether the machine is gone or only the agent is. Every service on it is reported as one host outage, not twelve.

Blast radius

Where the monitor lives decides what it can see.

Alerting has to sit outside the thing it alerts on. That is not a knock on Uptime Kuma, it is a property of any monitor you host yourself.

Uptime Kuma on the host it watches

Dies with the host.

Kernel panic, full disk, power cut: the monitor goes down in the same second as everything it monitors. The last state it ever showed was all green, and nothing is left to send the alert.

last seen 14:21 · all monitors up

Uptime Kuma on a second box

Works, with homework.

Now there are two machines to keep up, the second one needs tailnet reachability to every service, and it still only sees the tailnet FQDN from the outside. When the whole host goes, you get one alert per service and no word on the host itself.

12 monitors down · cause: ?

DockTail Cloud

Detection runs outside your network.

The agent dials out; nothing dials in. Silence from a host is itself the signal, and other agents on the tailnet report whether the device is still in their netmap. One host incident, with the vitals from right before it stopped talking.

host down · prod-01 · last seen 4m ago · mem 98%

Configuration

One monitor per service, or zero.

In Uptime Kuma every service is a monitor you create: a type, a URL or host and port, an interval, a notification. It is quick the first time and stale the third time a container gets renamed, moves to another host, or comes up on a different Docker IP.

Cloud has no monitor to create. The docktail.* labels that publish the service are the monitor definition, and the target is read from Docker on the host, on every pass. Add a labeled container and it is watched. Remove it and its monitor retires with it.

The whole monitor definition docker-compose.yml 
grafana:
  image: grafana/grafana:11.3.0
  labels:
    - docktail.service.enable=true
    - docktail.service.name=grafana
    - docktail.service.port=3000
You already wrote this to publish the service. Nothing else to add.

Side by side

Cloud, Uptime Kuma, and the admin console.

The honest comparison is against the two free tools people actually use together: Uptime Kuma for liveness and the Tailscale admin console for exposure. Cloud is the intersection.

DockTail Cloud Uptime Kuma Tailscale admin console
Monitors derived from Docker labels ✅ Nothing to define ❌ One monitor per service, by hand — Not a monitor
Tells container, exposure and host apart ✅ Two vantages read together ❌ Up or down ❌ Exposure only
Docker evidence on the incident ✅ Exit code, OOM, healthcheck, restart loop, log tail ⚠️ Container monitor: running or not ❌
Tailscale service approval state ✅ Read from the control plane, alerts on it ❌ ⚠️ Shown, but nothing alerts you
Keeps detecting when the host dies ✅ Detection runs in Cloud ⚠️ Only if hosted somewhere else ⚠️ Device shows offline, no alert
Host vitals without a metrics stack ✅ CPU, memory, load, temperature ❌ ❌
Funnel services probed from the public internet ✅ Cloud probes them itself ⚠️ If Kuma runs outside your tailnet ❌
Alert channels ✅ Slack, Telegram, ntfy, webhook, email ✅ 90+ providers ❌
Public status pages ❌ ✅ ❌
Monitors things that are not Docker containers ❌ DockTail services and the hosts they run on ✅ HTTP, ping, DNS, TCP, certificates ❌

Uptime Kuma column is based on the project's own documentation. If we got something wrong, tell us.

Keep Uptime Kuma if

You need a status page, or you monitor more than containers.

  • →You publish a public status page for other people.
  • →Your targets are URLs, DNS records, certificate expiry, or machines without Docker.
  • →Free and self-hosted is the requirement, not a preference.

Add Cloud if

The next alert should already say what to do.

  • →Your services are DockTail containers on one or more hosts.
  • →"Down" has cost you an evening of SSH before, and you would rather read exit 137 in the alert.
  • →A whole host going quiet should be one page, sent by something that is not on that host.

Both run side by side. Cloud publishes no ports and touches no monitor of yours, so it never gets in Uptime Kuma's way.

Questions

Cloud next to Uptime Kuma.

What does a Cloud incident say that an Uptime Kuma alert does not?
Which layer broke, and the evidence for it. A container problem carries the Docker event: exit code, OOM kill, failing healthcheck or restart loop, plus a log tail captured at the moment it happened. An exposure problem carries the Tailscale control-plane state: awaiting approval, not advertised by this host, or gone. A host problem means the heartbeats stopped.
Do I have to create monitors in DockTail Cloud?
No. The docktail.* labels that publish a service are its monitor definition, and the target is read from Docker on the host on every pass. Add a labeled container and it is watched. Remove it and its monitor retires with it.
What happens when the whole host goes down?
Detection runs in Cloud, not on the host. The agent dials out and nothing dials in, so silence from a host is itself the signal, and other agents on the tailnet report whether the device is still in their netmap. You get one host incident with the vitals from right before it stopped talking, not one alert per service.
Can I keep running Uptime Kuma?
Yes. Cloud is the DockTail agent you already run plus one environment variable, DOCKTAIL_CLOUD_KEY. It publishes no ports and touches none of your monitors, so Uptime Kuma stays exactly where it is.
When is Uptime Kuma the better choice?
When you publish a public status page, when your targets are URLs, DNS records, certificate expiry or machines without Docker, or when free and self-hosted is a requirement. Cloud monitors DockTail services and the hosts they run on, and has no public status pages.

Other comparisons

DockTail next to the other tools.

All comparisons →

DockTail (the agent)

Getting Docker containers onto a tailnet, or onto the internet.

One environment variable

Try it for 30 days.

Set DOCKTAIL_CLOUD_KEY on an agent you already run and leave Uptime Kuma exactly where it is. Homelab and Team start with a 30-day trial of the full plan; cancel before it ends and you are not charged.

Start 30-day trial See pricing