Uptime Kuma Shows Down but the Container Is Running: How to Diagnose It

Capture the exact failing request

Write down the monitor type, URL, accepted status codes, redirect behavior, timeout, authentication and latest error. Redact credentials before sharing diagnostics. “Container is running” is a process observation; a healthy HTTP check additionally requires an address that resolves, a reachable listener and an acceptable response.

Before changing anything, compare the host's result with the monitor's result at the same time. A browser can use a different DNS answer, saved session or public proxy route.

Check from the monitoring container

For an example deployment whose Kuma container is named uptime-kuma, this uses its Node runtime to make a bounded request. Replace the example URL and container name. It prints response metadata, not the body or credentials.

docker exec uptime-kuma node -e '
fetch(process.argv[1], {
  signal: AbortSignal.timeout(10000), redirect: "manual"
}).then(r => {
  console.log("status", r.status);
  console.log("redirect", r.headers.get("location"));
  if (!r.ok) process.exitCode = 1;
}).catch(e => {
  console.error(e.message, e.cause?.code || "");
  process.exitCode = 1;
});
' 'http://app:8080/health'

This tests the network context and a basic HTTP request. It does not reproduce every Kuma monitor setting: match authentication, method and redirect policy separately. Node's fetch support is required; if unavailable, use an approved diagnostic tool in that same network context.

Interpret the result

Docker's network documentation (opens in a new tab) explains container network isolation and DNS. With a mapping such as 8088:8080, a client using the host's published address connects to port 8088; a peer reaching the container directly uses its listening port 8080. localhost inside Kuma refers to that container unless you deliberately use a networking mode that changes this behavior.

Do not disable certificate validation or accept every HTTP status to turn the dashboard green. If a private CA is intended, configure trust. If authentication is required, give the checker a narrowly scoped account.

Verify the fix both ways

Record the failing observation, make one configuration change and repeat it. Then stop a disposable demo service. Kuma should report the failure and the expected responder should receive it. Restore the service and confirm recovery. A fix that only makes the success case green may have disabled the check's ability to detect failure.

Keep the target URL and network choice in the service runbook, along with a redacted copy of the error. The upstream troubleshooting page (opens in a new tab) is useful for version-specific investigation after locating the failing layer.