Monitoring

The Monitoring section of a server (/servers/:id/monitoring) is the box’s observability surface: historical CPU / RAM / disk / network charts, a live snapshot, the top processes, threshold-based alert rules, and a live Logs tail — all from real agent data. It’s available on all plans. Two tabs live here: Metrics (the default) and Logs.

Create an alert rule, step by step

1. Scroll to Alert rules and click New rule to open the rule drawer.
2. Give it a Title (e.g. “CPU above 90%”).
3. Pick the Metric — CPU %, RAM %, Disk %, Swap %, Load (1m), Network KB/s, or a container-health metric (unhealthy / stopped containers).
4. Set the Operator (>, <, ==) and a Threshold.
5. Set the Duration — how long the condition must hold before it fires (e.g. 5m; immediate fires on the first breach). This is the anti-flap window.
6. Choose a Severity (warning or critical) and tick the Channels to notify. Channels come from your account-wide Chat & Alerts connections.
7. Leave Active on and Create rule. The rule persists on the control plane and the alert worker starts evaluating it against every heartbeat.

Tip

Rules re-notify at most once an hour while firing, and send a one-shot “resolved” notice on recovery — so a long outage won’t spam your channels.

What else you can do

• Read the charts — four cards (CPU, RAM, Disk, Network rx/tx) plot real history bucketed from agent heartbeats. Hover for a crosshair chip naming the exact time and value; a gap reads “no data” rather than a carried value.
• Change the time range — the 1h / 6h / 24h / 7d / 30d segmented control re-buckets the history. Longer ranges fill in as history accumulates.
• Go Live — the Live toggle flips the shared poll cadence to ~3s (vs ~15s) so the headline numbers update in near real time. It drives the right-sidebar gauges in lock-step, so the two can never disagree.
• Live snapshot — uptime, 1-minute load, memory, swap, process count, top CPU process, kernel and hostname from the current mz metrics reading.
• Top processes — the live “what’s eating the box” table; toggle By CPU / By RAM to find a runaway process.
• Manage rules — pause/resume, edit, or delete any rule; a firing rule shows a pulsing Firing pill.
• Channels — the connected notification destinations are listed with a Send test; add or edit them in Chat & Alerts (one place, reused by rules here and by Uptime).
• Logs tab — a live-feeling tail of the box’s system and service logs (nginx access/error, php-fpm, mariadb, syslog, auth). Pick a source and Refresh to re-run the tail.

How it works

Monitoring stitches together three real data paths:

• Charts read GET /v1/servers/:id/metrics/history?range=…. The agent appends one metric sample per heartbeat into the server_metrics table; the API buckets and averages that series per range (CPU, RAM, disk, swap, load, net rx/tx). This works even while the box is briefly offline, since it reads stored history.
• Live snapshot, headline numbers and top processes come from the metrics.get job — the agent runs mz metrics --json natively. The same snapshot feeds the right-sidebar gauges and the Servers list cards, so every surface shows one number.
• Alert rules are persisted per-server on the control plane. A server-side alert worker loads active rules each tick, reads each server’s latest heartbeat metrics, evaluates the threshold against the duration window, and — on transition to firing — delivers to the rule’s channels over real HTTPS (webhook / Slack / Telegram). Email delivery needs SMTP configured on the control plane. Container-health metrics are computed from the agent-pushed Docker inventory cache, not the heartbeat.
• Logs dispatch a logs.tail job — the agent runs mz logs <target> --json and returns a one-shot snapshot of that log file.

CLI & automation

The metric and log reads are plain box-level mz commands — the same engine the dashboard drives. SSH in and run them, or let an on-box AI (ClaudeCode) read them the same way:

mz metrics --json                     # the live snapshot (CPU, RAM, load, top procs)
mz logs sources --json                # which log targets the box exposes
mz logs nginx-error --lines 200 --json
mz logs syslog --lines 200 --json

Alert rules are managed on the control plane (dashboard or the API), not through mz. See The mz CLI and the command catalog.

Gotchas & troubleshooting

• History accumulates from when monitoring began. The charts render only the samples already stored, so a fresh server shows “Collecting metric history…” and the longer ranges (7d / 30d) fill in over time — they are not back-filled.
• A rule only fires while the box is heartbeating. The alert worker evaluates the last heartbeat metrics; if the agent is fully offline there are no new samples to breach a threshold. Use Uptime monitoring for “is the box/site reachable at all” — it probes from the outside and is the right tool for hard-down detection.
• Email channels can be saved but inert. Webhook / Slack / Telegram deliver with no extra infrastructure; email is only sent if the control plane has SMTP configured, otherwise the channel is skipped with a logged warning.
• Offline shows a Preview banner with example data. When the agent is offline the section still renders (with a “Preview” banner and last-known/example values) so the layout is reviewable, and the Logs tab falls back to synthetic sample lines. Live reads, the snapshot, and log tails resume when mzagent reconnects.
• ?tab=logs deep-links the Logs tab. The old /servers/:id/logs route now redirects here, so bookmarks keep working.

Related

• Cron jobs — scheduled tasks and per-job run logs.
• Uptime monitoring — external reachability checks and incidents.
• The mz CLI — driving the box from the command line.