← Blog

Uptime monitoring for Docker Compose on a VPS

Docker Compose on a small VPS (Hetzner, DigitalOcean Droplet, Linode) is a common homelab and early-production pattern: nginx or Traefik in front, app containers behind, Postgres on an internal network. You should monitor one public ingress — not every internal service port from the internet.

StillOnline runs HTTP GET checks from outside your VPS, hosts a status page, and alerts you via the StillOnline Telegram bot, Slack, or email. You do not run a monitoring container on the same host unless you want to — external truth catches DNS, TLS, and reverse-proxy failures Coolify/Compose UI miss.

Quick answer

Docker Compose on a VPS should expose GET /health on the public HTTPS domain where nginx or Traefik terminates TLS — returning 200, not on http://app:3000 or localhost. Register that URL in StillOnline; Free runs five-minute checks on one URL (pricing). Internal Postgres, Redis, and workers stay off external checks. See Hetzner + Coolify and open-source vs hosted status page.

One ingress, not every container

ServiceExternal StillOnline check?
nginx / Traefik → appYes — /health on public domain
Postgres on internal networkNo — optional ping inside app /health only
Redis, worker, queueNo public check — use heartbeat pattern later
Admin port exposed by mistakeDo not register — fix firewall instead

StillOnline probes the same URL customers use, matching health check quickstart.

Typical Compose pitfalls

ProblemSolution
Health curls localhost inside containerTest from outside the VPS
Only monitoring Compose UI (Portainer)UI up ≠ app domain up
Cert expired on nginxExternal check fails — fix TLS
docker compose restart blipShort red period — maintenance post
curl -sS -o /dev/null -w "%{http_code}\n" https://api.yourproduct.com/health

StillOnline setup

  1. Sign in.
  2. New project.
  3. HTTP check → public /health, GET, 200, five-minute interval (Free).
  4. Status page link in docs if you have paying users — public status page guide.

SettingsConnect TelegramStillOnline botTelegram guide.

Free: one URL. Pro: more checks for separate public webhook host — pricing.

Homelab vs indie SaaS

Homelab builders often run Uptime Kuma on the same box — that dies when the VPS is down. External StillOnline checks survive host outages you cannot self-ping — Kuma vs hosted. Once you have B2B customers, a hosted status page beats SSH-only incident comms.

Related guides

FAQ

Should StillOnline ping each Docker Compose service?

No. Use one public health URL through your reverse proxy. Internal services are validated inside that health handler if needed — health endpoint design.

Can I monitor http://127.0.0.1:8080/health?

Only if that port is publicly reachable on the internet — usually a bad idea. Prefer HTTPS on your domain.

Does StillOnline install an agent on my VPS?

No. External HTTP probes only — no container to add to Compose.

When should a homelab use StillOnline instead of self-hosted Kuma?

When you need a customer-facing status page and alerts that work when the VPS is unreachable — status page without Kuma · open-source vs hosted.