coolify-observability — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited coolify-observability (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Covers Sentinel monitoring, notification channels, log drains, external monitoring integration, and resource observability for Coolify v4 self-hosted.
Self-Hosted Only: All content assumes self-hosted Coolify v4.x. Monitoring and log drain features may differ on Coolify Cloud.
┌─────────────────────────────────────────────────────┐
│ Coolify Server │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Sentinel │───►│ Coolify Core │──► Notifications│
│ │ (metrics │ │ (dashboard, │ (Slack, │
│ │ collection) │ │ alerts) │ Discord, │
│ └──────────────┘ └──────┬───────┘ Email...) │
│ │ │
│ ┌──────────────┐ ┌──────┴───────┐ │
│ │ App Containers│───►│ Log Drains │──► External │
│ │ (stdout/err) │ │ (Axiom, │ Services │
│ └──────────────┘ │ Loki, etc.) │ │
│ └──────────────┘ │
│ │
│ ┌──────────────┐ │
│ │ Uptime Kuma │ (optional, deployed as service) │
│ │ (HTTP checks)│ │
│ └──────────────┘ │
└─────────────────────────────────────────────────────┘Honest scope. Sentinel is a lightweight metrics side-car, not a full observability solution. It collects CPU/RAM/disk/network metrics and exposes them in the Coolify UI. It does not include log aggregation, distributed tracing, alerting beyond simple threshold notifications, or APM features. Coolify itself flags Sentinel as experimental in the docs (the feature page carries a CAUTION banner). Sentinel does not support Docker Compose deployments or Service Template deployments — only single-container managed apps. If you need real observability, layer on Grafana+Prometheus or an external APM (Datadog, New Relic) — see the log drains section below.
Sentinel runs as a Docker container (coolify-sentinel) on each managed server:
| Metric | Description | Collection Interval |
|---|---|---|
| CPU Usage | Per-container and server-wide CPU % | ~10 seconds |
| Memory Usage | Per-container and server-wide memory | ~10 seconds |
| Disk Usage | Server disk space used/available | ~60 seconds |
| Network I/O | Bytes in/out per container | ~10 seconds |
| Container Status | Running, stopped, restarting | Real-time (Docker events) |
| Server Connectivity | Server reachability from Coolify main | Heartbeat |
Not covered by Sentinel: request latency, error rates, distributed tracing, log search, custom application metrics, multi-server aggregated dashboards. For these, use the log drain integrations or external APM described later in this skill.
Configure in Settings → Notifications:
| Channel | Configuration | Supported Events |
|---|---|---|
| SMTP settings (host, port, user, pass, from address) | All | |
| Slack | Webhook URL | All |
| Discord | Webhook URL | All |
| Telegram | Bot token + chat ID | All |
| Custom Webhook | URL + optional headers | All |
api.slack.com/messaging/webhookshttps://hooks.slack.com/services/T.../B.../xxx)@BotFather in Telegram → get the bot tokenhttps://api.telegram.org/bot<TOKEN>/getUpdates)| Destination | Type | What's Sent |
|---|---|---|
| Axiom | SaaS | Container stdout/stderr, build logs |
| New Relic | SaaS | Container logs with metadata |
| Highlight.io | SaaS | Container logs |
| Custom HTTP/Fluentd | Self-hosted or SaaS | Raw log lines via HTTP POST |
https://log-api.newrelic.com/log/v1 (US) or https://log-api.eu.newrelic.com/log/v1 (EU)For Loki, FluentBit, Datadog, or any HTTP endpoint:
Authorization: Bearer <TOKEN>)After configuration:
docker ps | grep sentinelUptime Kuma is deployed as a Service (one-click) in Coolify:
status.example.com)| Monitor Type | Use For | Configuration |
|---|---|---|
| HTTP(s) | Web apps with health endpoints | URL: https://app.example.com/healthz, interval: 60s |
| HTTP(s) - Keyword | Verify specific response content | Check for "ok" or "healthy" in response body |
| Docker Container | Monitor container directly | Requires Docker socket access (add as Docker host) |
| TCP Port | Non-HTTP services (databases, Redis) | Host: container name, Port: service port |
Expose a /healthz endpoint in every application:
// Express.js
app.get('/healthz', async (req, res) => {
// Check dependencies
const dbOk = await checkDatabase();
const redisOk = await checkRedis();
if (dbOk && redisOk) {
res.status(200).json({ status: 'ok', db: 'connected', redis: 'connected' });
} else {
res.status(503).json({ status: 'degraded', db: dbOk, redis: redisOk });
}
});# FastAPI
@app.get("/healthz")
async def healthz():
db_ok = await check_database()
return {"status": "ok" if db_ok else "degraded", "db": db_ok}Uptime Kuma has its own notification system (separate from Coolify's):
For advanced monitoring, deploy a Prometheus + Grafana stack alongside Coolify:
cAdvisor setup (container metrics for Prometheus):
services:
cadvisor:
image: gcr.io/cadvisor/cadvisor:latest
volumes:
- /:/rootfs:ro
- /var/run:/var/run:ro
- /sys:/sys:ro
- /var/lib/docker/:/var/lib/docker:ro
ports:
- "8081:8080"For application-level monitoring (APM, traces, not just logs):
This is application-specific, not Coolify-specific — follow the APM provider's Docker documentation.
| Anti-Pattern | Consequence |
|---|---|
| No notification channel configured | Deployments fail silently; containers crash without anyone knowing |
| Setting disk alert threshold to 95% | Too late — Docker and Coolify may malfunction before you can act |
| Not deploying Uptime Kuma or external monitoring | Rely solely on Coolify dashboard; miss issues when Coolify itself is down |
| Sending all container logs to a paid SaaS without filtering | Expensive log ingestion bills for debug/verbose logs |
| Not testing notification delivery after setup | Discover broken notifications during an actual incident |
| Monitoring only HTTP status, not response time | Miss gradual performance degradation |
| Running Prometheus + Grafana on the same server as production apps | Monitoring stack competes for resources with production |
| Not setting up a status page for end users | Users don't know about outages; support tickets spike |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.