Skip to content
Knowledge base

Monitor a Coolify app from outside the server

Coolify's own health checks run on the same box as the apps they watch, so the failure that matters most, the server itself going away, is the one they can never report. How to add an independent outside vantage: the Monitor agent on the Coolify host, an HTTP check per deployed app, and a status page.

1. Know why the checks have to come from outside

Coolify health-checks the containers it deploys, and that works right up to the failure you most need to hear about: the VPS itself going down, losing its network, or running out of disk. When the host dies, everything on it dies together, including the thing that was supposed to alert you. An independent monitor probes each app from the outside, from infrastructure that shares nothing with the server it is watching, so "the whole box is gone" produces an alert instead of silence.

2. Install the Monitor agent on the Coolify host

Register an agent from Monitor settings in the dashboard, then run the one-line installer on the Coolify host itself, or add the agent as one more service in Coolify's Docker Compose resource type so Coolify manages it like everything else on the box. Either way it reports the host's CPU, memory, disk, and load, which is how you see "the box is filling up" before it becomes "every app is down". The agent is outbound-only: it opens no inbound port and never runs a command RealUptime sends.

3. Add one HTTP check per deployed app

Point a check at each app's public domain, the address a real visitor uses, not the internal Coolify network name. Each check probes from the regions you select and each region reports separately, so a CDN or routing problem that only affects part of the world reads as exactly that instead of averaging away. On http checks you can also assert on status range and body content, so a page that answers 200 with an error message still counts as down.

4. Give scheduled tasks a heartbeat instead

Anything Coolify runs on a schedule, backups above all, serves no requests, so there is no URL to probe. Create a heartbeat monitor for each one and add a ping to the end of the task, gated on the work actually succeeding. The monitor goes down when pings stop arriving, which catches the job that silently stopped running, the failure no outside probe can see.

5. Finish with a status page

Add the host (via the agent) and each app check as components on one status page, so a visitor can tell "one app is down" from "the whole server is unreachable". The page updates from the same probes that alert you, so it cannot say less than what was measured.

Go deeper

The full reference lives in the docs: RealUptime + Coolify documentation. Error codes named above are each explained in the error-code reference.