.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Coolify monitoring has two layers and most people only set up one of them. The first layer is Sentinel, the lightweight agent Coolify ships out of the box that tracks CPU, memory and disk per container and surfaces it inside the dashboard. The second layer is whatever you wire up on top, usually Prometheus and Grafana, to get historical data, custom dashboards and alerts that don't depend on the Coolify control plane being healthy.
Both layers matter. Sentinel is great for "what's happening right now" and built-in notifications. Prometheus and Grafana are the right tools when you want a six-month CPU graph or an alert that fires before the disk fills up at 4 AM. This guide covers both, written against Coolify v4.0.0.
If you want to follow along on a working Coolify install, the LumaDock Coolify VPS ships with v4 pre-installed. The getting started guide covers initial dashboard access if you're new.
What Coolify monitoring covers out of the box
The built-in monitoring story is Sentinel. It's a small Docker container that runs on each managed server, samples CPU and memory roughly every 10 seconds, disk usage about every 60 seconds and ships the data back to the Coolify control plane. The result shows up in the dashboard as the per-container CPU and memory bars and the per-server disk usage indicator.
Sentinel also exposes a local HTTP API at localhost:8888 on the server it runs on. The API returns historical metrics in JSON. Most users don't touch this directly, the dashboard reads it for them. But if you want to scrape Coolify metrics into something else, the API is the integration point.
What Sentinel doesn't do well: long-term historical retention, custom dashboards, multi-condition alerts, query-time aggregation across servers. For any of those, you want Prometheus and Grafana on top.
Where to enable Sentinel in the dashboard
Sentinel is enabled per server. Go to Servers in the left sidebar, pick your server, then look for the Sentinel toggle in the server settings. On a fresh Coolify install Sentinel is usually on by default. If it's off, the dashboard won't show real-time metrics.
Note that Sentinel has historically caused 100% CPU usage on certain configurations (see issue 2807) and a flaky "server unreachable" notification pattern (issue 4407). Both have been worked on across recent releases. If you upgrade Coolify and start seeing weird metric behavior, check those issues for the current state.
Set up Coolify notifications first
Before you reach for Prometheus, get notifications working. Coolify v4 has a redesigned notification system that sends events to Email, Slack, Discord, Telegram, Pushover or a generic webhook. The events you can subscribe to include:
- Deployment Success / Failure, fires when an application deploy finishes
- Backup Success / Failure, fires when a scheduled database backup runs
- Scheduled Task Failure, fires when a cron-style task you defined errors out
- Server Disk Usage, fires when the server crosses your configured threshold
- Server Reachable / Unreachable, fires when Coolify loses contact with a managed server
To configure, click your profile icon, go to Notifications, then enable the channels you want. For a small team, Discord with a single webhook URL is the path of least resistance. For incident-aware setups, route Server Unreachable and Backup Failure to a paging tool (PagerDuty, Opsgenie or a webhook into your incident system) and route Deployment Success to a less noisy channel.
The granularity of the notification system is the win. You can have different events go to different channels per project, which means you don't end up training your team to ignore deploy success messages because they're mixed in with actual production alerts.
Add Prometheus and Grafana for proper monitoring
Once notifications are running, layer Prometheus and Grafana on top for historical metrics and custom alerting. Both are available as one-click services in Coolify, which means installing them is the same flow as deploying any other application.
Step 1, deploy Prometheus as a one-click service
Inside any project in Coolify, click Add a new resource, then pick Service from the resource type list. Search for Prometheus. Coolify pulls the Prometheus service template, which is a Docker Compose file with sensible defaults. Click Deploy.
Prometheus comes up on its default port (9090) inside the Coolify Docker network. By default it doesn't have any scrape targets configured. We'll add those next.
Step 2, configure scrape targets
Prometheus needs to know what to monitor. The targets you'll typically want for a Coolify setup are:
- Node Exporter, for host-level metrics (CPU, memory, disk, network) on each Coolify server
- cAdvisor, for per-container metrics on each server
- Application metrics, if your apps expose a Prometheus endpoint (Node.js apps with prom-client, Django with django-prometheus, Laravel with the prom-php package, etc.)
Deploy Node Exporter and cAdvisor on each server you want to monitor. Both are also one-click services in Coolify. Once they're running, edit your Prometheus configuration to add their endpoints as scrape jobs. The config file lives in the persistent volume Coolify mounts on the Prometheus container, typically at /etc/prometheus/prometheus.yml inside the container, mapped to a volume on the host.
A minimal scrape config for a single Coolify server looks like:
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['node-exporter:9100']
- job_name: 'cadvisor'
static_configs:
- targets: ['cadvisor:8080']
- job_name: 'coolify-sentinel'
metrics_path: '/api/metrics'
static_configs:
- targets: ['host.docker.internal:8888']The host.docker.internal hostname lets the Prometheus container reach Sentinel running on the host. Save the config, restart Prometheus from the Coolify dashboard so it picks up the changes.
Step 3, deploy Grafana and connect Prometheus
Inside the same project, add another resource of type Service and pick Grafana. Coolify deploys Grafana on its default port (3000) and Coolify can route a custom domain to it.
Open the Grafana UI, log in with the default admin credentials Coolify generated for you (visible in the resource's environment variables tab) and change the password immediately. Then add Prometheus as a data source, the URL to use is http://prometheus:9090 if both are in the same Coolify project on the same Docker network or http://host.docker.internal:9090 if they're on different networks.
From here you can import any of the standard Grafana dashboards. Dashboard 1860 is the canonical Node Exporter Full dashboard. Dashboard 14282 is a popular cAdvisor + Docker dashboard. Both work out of the box once Prometheus has data flowing.
Step 4, configure Grafana alerts
Grafana's alerting is more flexible than Coolify's built-in notifications because you can write multi-condition rules. The alerts you actually want for a Coolify setup:
- Disk usage above 80%, alerted to your incident channel. Catches the slow-build-up problem before Coolify itself starts misbehaving
- Memory usage above 90% sustained for 5 minutes, alerted to incident. Catches OOM-bound containers before the OOM killer fires
- CPU usage above 90% sustained for 10 minutes, alerted to a low-priority channel. Useful for spotting runaway processes
- Container restart count rising, alerted to incident. Containers that crash-loop silently are a common Coolify failure mode
- Coolify control plane down, alerted to incident via a separate alerting tool (since if Coolify is down, Grafana might be too if it's on the same host). Use an external uptime monitor like Uptime Kuma, BetterStack or a simple cron-based ping
Configure each alert in Grafana with a contact point pointing at the same Slack/Discord/email destination Coolify uses or a different one if you want monitoring alerts separated from deploy notifications.
Application-level monitoring on Coolify
Host and container metrics catch infrastructure problems. Application metrics catch business problems. The pattern that works is to expose a Prometheus-compatible /metrics endpoint on each application and add it as a Prometheus scrape target.
Node.js applications
Use the prom-client package. It exposes default Node.js metrics (event loop lag, memory usage, GC pauses) plus custom metrics you define. The Node.js Prometheus and Grafana monitoring guide walks through the full setup including custom HTTP request duration metrics.
Django applications
Use the django-prometheus package. Add it to INSTALLED_APPS, wrap your URL config and you get default request metrics, query metrics and cache hit rates. Detailed setup is in the Django on Coolify guide.
Laravel applications
Use the spatie/laravel-prometheus package or roll your own metrics endpoint. The Laravel app's queue worker is the part you'll most want to monitor (job throughput, failed job count, queue depth). The Laravel on Coolify guide covers the queue worker setup.
Other stacks
Almost every popular framework has a Prometheus integration. SvelteKit can use prom-client the same way as Node.js. Go uses prometheus/client_golang. Rust uses prometheus crate. Rails uses prometheus-client. Add the metrics endpoint, register it as a Prometheus scrape target, write the alerts you care about.
What to alert on
Most monitoring setups fail because they alert on too much. The result is alert fatigue, the team starts ignoring alerts and the actual production failures get missed because they're buried in the noise.
Practical rules for a Coolify setup:
Alert on conditions that require human action, not on data points you find interesting. Disk filling up requires action (delete things or add space). CPU at 70% probably doesn't.
Alert with sustained-condition rules, not instant triggers. A CPU spike for 10 seconds isn't a problem. CPU at 95% sustained for 10 minutes is.
Route different severity to different channels. Server unreachable goes to PagerDuty. Disk above 80% goes to a Slack channel. Build success goes nowhere or to a low-noise channel.
Have at least one external monitor that doesn't depend on Coolify being healthy. If Coolify itself is down, you want to know from a third-party uptime check, not from a Grafana alert that's also down.
Common Coolify monitoring problems and how to fix them
Sentinel reports 100% CPU usage all the time
Older Coolify versions had a Sentinel bug where the agent itself consumed full CPU on certain configurations. Fix: update Coolify to the latest version. If it persists, see issue 2807 for the current state and consider disabling Sentinel temporarily until it's resolved.
False "server unreachable" notifications
Documented in issue 4407. Usually caused by the SSH connectivity check timing out under load. Workarounds include increasing the timeout in server settings, ensuring the Coolify host has stable network to managed servers and adding the alert to a low-priority channel rather than a paging tool until the underlying issue is fixed upstream.
Prometheus shows targets as down
Almost always a network reachability issue between containers. Check that Prometheus and the target services are on the same Docker network or use host.docker.internal if they're on different networks. Run docker exec into the Prometheus container and try wget -O- http://target:port/metrics to confirm reachability.
Grafana shows no data even though Prometheus has it
Data source URL is wrong or the time range is wrong. Test the data source from Grafana's UI (Settings, Data Sources, Test). Check the dashboard time range matches when your data exists. If both look right, the queries themselves might be using the wrong job or instance label, edit the panel and inspect the query.
Disk fills up because of Docker image bloat
Coolify keeps old Docker images around for rollback. Over time these accumulate. Run docker system prune -a on the host every few weeks or set up a cron task to do it monthly. The Coolify database backups guide covers a related cleanup pattern for backup files.
What next?
Once monitoring is running, the natural next steps are tightening security on the underlying server (the production server security guide covers SSH hardening, firewall rules and Fail2ban) and setting up automated database backups so the metrics you're watching aren't the only thing standing between you and data loss. The Coolify backups guide covers Postgres, MySQL and MongoDB backups to S3-compatible storage.
If you're running Coolify across multiple servers, the same monitoring stack scales. Deploy Node Exporter and cAdvisor on each server, add them all as Prometheus scrape targets, build a single Grafana dashboard that aggregates by server label. The hostname becomes a dashboard variable so you can filter the view per server when you're investigating.
