---
title: "Coolify monitoring: what it covers and what it misses | Logdash"
description: "Coolify alerts on stopped containers, unreachable servers and disk usage, but never checks a public URL. Health checks, /api/health and a Telegram alert."
url: https://logdash.io/monitor/coolify
---

# 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 

```yaml
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:

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

## Coolify uptime from outside

1. **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.
2. **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.
3. **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? 

Add each app's public health route and the Coolify /api/health endpoint to an external monitor. Logdash checks them every 5 minutes on the free plan and sends a Telegram alert when one stops answering 200 to 399.

## Keep reading

[All platforms](https://logdash.io/monitor): One page per platform, each with what it already monitors, the gap, and a Telegram alert in three steps.

[Hetzner server monitoring](https://logdash.io/monitor/hetzner): Hetzner Cloud draws CPU, disk and network graphs for every server but sends no alert when one stops answering, so you add an outside HTTP check against a health path on the server or load balancer and route its alert to Telegram.

[DigitalOcean droplet monitoring](https://logdash.io/monitor/digitalocean): DigitalOcean already covers droplet monitoring with free resource alerts once you install its metrics agent and Uptime checks at $1 a month each after the first, so an outside monitor earns its place only for Telegram or webhook alerts, sub-minute checks, or a status page.

[VPS monitoring](https://logdash.io/monitor/vps): VPS monitoring means an outside check that alerts you when the server stops answering, plus a heartbeat from inside that stops when the disk fills or the app dies, because most provider dashboards give you graphs rather than alerts.

[Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.