Monitoring & alerts
Monitoring is on by default. When a server is provisioned you get live metrics, ten sensible alert rules, uptime checks and an optional public status page, with nothing to configure.
Metrics
- Servers: CPU (total and per core), load, memory, swap, disk and network rx/tx.
- Containers: CPU %, memory, network, state and restart count.
- Resolution: raw 10-second points for 48 hours, 1-minute rollups for 14 days, and 1-hour rollups for the configured retention (Settings → Metrics retention).
- Live: charts update over server-sent events as each report arrives.
Ranges up to 6h use raw points, 24h–7d use minute rollups, and 30d uses hourly rollups. Every chart is downsampled to at most 400 points, so it stays fast.
Default alert rules
These rules are created on first start and apply to every server and app:
| Rule | Condition | Severity |
|---|---|---|
| CPU | > 90% for 5 min | warning |
| Memory | > 90% for 5 min | critical |
| Disk | > 85% | warning |
| Disk | > 95% | critical |
| Server offline | no agent report for 2 min | critical |
| Container down | a managed container isn't running | critical |
| Container restarts | > 3 in 10 min | warning |
| Deploy failed | any failed deployment | warning |
| Uptime down | an uptime check fails | critical |
| Backup failed | a backup run or its verification fails | critical |
You can edit thresholds, disable rules, or add your own. A rule can be scoped to one server or app, or apply to all of them. Metric rules support cpu, mem, disk, load and swap.
How alerts behave
- Each condition has one firing alert, so you're not spammed. Repeats are deduplicated.
- An alert resolves automatically when its condition clears, and you're notified then too.
- Acknowledge an alert to show that someone is on it.
- Messages are short and human, and end with a hint: Ask Claude:
/docksy:diagnose prod-1.
Notification channels
| Channel | Config |
|---|---|
| Discord | webhook URL |
| Slack | incoming webhook URL |
| Telegram | bot token + chat id |
| Generic webhook | URL + optional secret (JSON POST) |
| SMTP host, port, TLS, user, password, from, to |
Each channel has a Test button. A rule with no channels selected notifies every enabled channel.
Uptime checks
- HTTP(S) checks every 30 seconds or more, with a timeout and an expected status (or any 2xx/3xx).
- When an app gets a domain, Docksy creates a check for it automatically after its first successful deploy.
- Results are kept for 90 days, with uptime % and average latency shown for the last 24 hours.
- A failing check fires the Uptime down alert, and recovery resolves it.
Public status page
Turn it on in Settings → Status page and choose which checks are public. It's served at /status, with an overall state (operational / degraded / down) and 90 days of daily uptime bars. It's disabled by default and returns 404 until you enable it.
Diagnose
Diagnose is a deterministic, rule-based health check for a server or an app. No AI runs inside Docksy. It returns findings with evidence, a suggestion, and often a ready-to-run fix that Claude can execute (with your consent). It checks:
- high CPU or memory, with the top containers by usage
- disk nearly full, with prune suggestions
- swap thrashing
- an offline agent
- restart loops and OOM-kills
- a failed last deploy, with its error and the build-log tail
- recent errors in app logs
- expired or missing TLS
- failing uptime checks
Click Ask Claude to diagnose on any server page, run docksy diagnose prod-1, or type /docksy:diagnose prod-1 in Claude Code. See Claude & MCP.