Coolify monitoring

Coolify watches its own servers and containers - reachability, container stops, disk usage, and CPU and memory through Sentinel - but it never requests your public URLs, so Coolify monitoring needs an outside check on each app and on the Coolify dashboard itself.

What Coolify monitoring covers

Container Status Changes: a container stops unexpectedly, restarts on its own, or hits its restart limit.
Server Reachable, Server Unreachable and Server Disk Usage for every connected server.
Deployment, backup and scheduled task success and failure.
Sentinel, the per-server agent, reports container state and Docker health, and with metrics on it keeps CPU and memory history, sampled every 10 seconds by default.
Alerts go to email, Discord, Telegram, Slack, Mattermost, Pushover or a webhook, with events chosen per channel.

That is more than most hosted platforms ship. Coolify's own docs draw the line: use external tools for public endpoint checks from outside your infrastructure.

What it cannot see

Every signal above comes from inside the server. A Traefik label pointing at the wrong port, a DNS record that moved, a firewall rule, or an app answering 500 from a healthy container all leave the container running and nothing fires. Worse, if Coolify runs on the same server as your apps and that server dies, the thing that would send Server Unreachable died with it. A Coolify instance can report on the remote servers it manages. Nothing reports on Coolify.

Container health checks

Under Configuration, Healthcheck, you pick HTTP or CMD, a path, an interval, a timeout and retries. The HTTP check runs inside the container, so the image needs curl or wget, or Docker marks it unhealthy and the rolling update keeps the old container. For the Docker Compose build pack, the health check lives in the compose file. This one uses Node's built-in fetch, so no curl is needed:

docker-compose.yml

services:
  app:
    build: .
    healthcheck:
      test: ["CMD", "node", "-e", "fetch('http://127.0.0.1:3000/health').then(r => process.exit(r.ok ? 0 : 1)).catch(() => process.exit(1))"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 20s

The Coolify dashboard has a public health endpoint of its own. It needs no token and answers a plain OK. Watch it from outside and you hear about the dashboard going down, the one alert Coolify cannot send about itself:

curl -fsS https://coolify.example.com/api/health
# OK

Coolify uptime from outside

Add the URLs Create a service in Logdash for each app, pointed at its public /health route, and one for https://coolify.example.com/api/health. Five fit in the free plan. Logdash only reaches public addresses, so apps behind a VPN or on a private network are out of reach.
Pick the interval Every 5 minutes on the free plan, every minute on Builder, every 15 seconds on Pro. Each check stores the status code and the response time.
Break it on purpose Stop the app from the Coolify dashboard. Traefik starts answering with an error instead of your app, the next check flips the monitor to down, and a Telegram alert lands with the status code. Coolify sends its own Container Status Changes alert too, and that is fine: one comes from inside, one from outside.

Logdash vs Coolify built-in monitoring

Feature	Logdash	Coolify built-in
Container stopped or restarting	Only if the URL starts failing	Container Status Changes event
CPU, memory and disk	Not measured	Sentinel metrics and a disk usage alert
Public URL answering	A GET every 5 minutes, 1 minute or 15 seconds	Not checked
The Coolify host itself dies	Alert from outside	Silent when Coolify ran on that host
Telegram alerts	Yes	Yes
Private network services	Cannot reach them	Sees every container it manages

When Coolify built-in is the better pick

Your apps are internal and never get a public URL. Coolify sees them, Logdash cannot.
Container state and disk space are what actually break on your box. Coolify alerts on both and Logdash on neither.
You want HTTP checks on your own hardware. Uptime Kuma is a one-click service in Coolify. Put it on a different server from the apps it watches.

Does Coolify monitoring include uptime checks?

No. Coolify monitoring covers server reachability, container status, disk usage and, with Sentinel metrics on, CPU and memory. It does not request your public URLs, and its docs recommend an external tool for that.

How does Coolify server monitoring work?

Sentinel runs on each server and reports container state and Docker health to Coolify, plus CPU and memory history when metrics are enabled. Coolify also checks that each server is reachable and how full its disk is, and sends alerts on the channels you pick.

Who watches the Coolify dashboard if its server goes down?

Nobody, unless you add an outside check. Point a monitor at /api/health on your Coolify domain. It is public, needs no token and returns OK, so a failure means the dashboard is unreachable.

How do I track Coolify uptime from outside?