How to monitor a Coolify deployment

Coolify is an open-source, self-hosted alternative to platforms like Heroku, Vercel, and Netlify. You install it on your own server, connect your Git repos, and it handles building, deploying, and running your apps in Docker containers. It manages SSL via Let's Encrypt, sets up a reverse proxy, and gives you a nice dashboard to see what's running.

What the dashboard shows you is container status. Green means the container is running. That's useful, but it doesn't tell you whether the app inside the container is actually working. A container can be running while the app is returning errors, failing to connect to its database, or stuck in a state where it accepts connections but never responds.

What to monitor

Each app by its domain. Coolify assigns each app a domain, either auto-generated or custom. Monitor the domain over HTTPS. This tests the full path: DNS resolution, the reverse proxy (Traefik or Caddy, depending on your Coolify version), TLS termination, and the app itself.

Health endpoints. If your app has a health check endpoint, prefer that over GET /. A health endpoint that verifies the database connection, checks that required services are reachable, and returns a non-200 status when something is wrong is far more useful than checking if the homepage loads.

SSL certificates. Coolify manages Let's Encrypt certificates automatically. But auto-renewal depends on the ACME challenge succeeding, which depends on DNS being pointed correctly at your server. If you change DNS providers, add a CDN, or misconfigure your domain, renewal fails silently and the certificate eventually expires. Monitoring certificate expiry gives you advance warning.

Coolify-specific failure modes

Proxy misconfiguration. Coolify has supported both Traefik and Caddy as reverse proxies at different points, and the proxy configuration is generated from your app settings. If something goes wrong with the generated config (a port mismatch, a missing domain entry, a conflicting route), the proxy returns errors while Coolify's dashboard still shows the container as running.

Webhooks not firing. Coolify can auto-deploy from GitHub webhooks. If the webhook stops working (GitHub rotated the secret, the webhook URL changed, Coolify's API is unreachable from GitHub), your pushes stop triggering deploys. You think you're shipping updates, but the running version is stale. This isn't something uptime monitoring catches directly, but if you're monitoring for specific response body content that should change after a deploy, you'd notice.

Resource exhaustion on the host. Like any self-hosted PaaS, all your apps share a single server's resources. One app with a memory leak can take down everything else. Coolify doesn't isolate apps from each other beyond Docker's default cgroup limits, and those aren't set by default for all configurations. Monitoring each app individually tells you which one stopped responding first.

Database connection limits. If you're running Postgres or MySQL through Coolify, and multiple apps connect to the same database, connection pool exhaustion is a real risk. The database container is running, Coolify says it's healthy, but new connections are refused. Your apps start failing on database operations while returning 200 on routes that don't need the database. Health endpoints that verify the database connection catch this.

Persistent storage issues. Coolify supports Docker volumes for persistent data. If a volume mount fails, the app starts without its data directory. Depending on the app, this might cause a crash, a fallback to defaults, or silent data loss. Health endpoints that read from the expected data path catch this.

Setting it up

Create an HTTP monitor in Larm for each app's public domain.

Timeout. Coolify apps run as persistent Docker containers, so cold starts aren't usually an issue. 5 seconds is reasonable. If your app does heavy initialization on the first request after a deploy, bump it up.

Keyword validation. Useful for catching "soft failures" where the app returns 200 but the content is wrong. If your health endpoint returns {"status":"ok"}, check for "ok" in the response body.

Multiple apps, multiple monitors. Don't assume that because one app is working, they all are. Create a separate monitor for each service you're running through Coolify.

Monitoring the underlying server

Coolify runs on a server, and server problems affect all apps. If you're on Hetzner (common for self-hosted setups), check the Hetzner monitoring guide for server-level concerns.

The combination you want is: HTTP monitors for each app (is this specific service working?) and a basic check on the server itself (is the machine reachable?). If all your app monitors go down at once, the problem is probably the server or the proxy, not the individual apps.

Coolify takes the pain out of self-hosting. Monitoring from outside is the piece that tells you it's all actually working. Larm's free plan gives you 15 monitors with multi-probe verification, enough for a typical Coolify server.