Skip to content

Metrics & Alerts

The Metrics tab shows what your server is actually consuming right now and over time. The Alerts tab on the same server creates rules and lists the incidents they fire.

  • A server you can access, with server.read for the Metrics tab.
  • alert.read to see alert rules and incidents, alert.create to add one, and alert.update / alert.delete to change or remove one. The Alerts tab also appears with server.read, but the rules and history in it need alert.read.

The header shows live detail — memory in use, disk used out of the total, and received traffic — while the agent is reporting. A stopped server reads zero CPU and memory rather than showing stale values; if the agent is offline, the panel keeps the last known values and says so.

Below the header are trend cards for CPU, Memory, Disk usage, Disk I/O, and Network (receive plus transmit, in MB/s). The latest value on each card turns amber past 75% and red past 90% for CPU and memory.

Each card is drawn on a scale that starts at zero — CPU against the whole allocation, so a line at the top of the card means every allocated core busy — and small readings keep the decimals they need instead of rounding to nothing: a server using a fraction of a core reads 0.01 / 4 cores · 0.35% of allocated cores, and anything under a hundredth of a core reads <0.01. A quiet server therefore draws a flat line along the bottom of its card rather than a spiky one.

Use the time range selector at the top right to change the window:

  • 1 hour, 6 hours, 24 hours, 7 days, 30 days.
  • Custom range — set Hours (1–8760) and Data points (1–1000).

Next to the selector, an Updated … stamp says when the history was last refreshed; hover it for the exact time.

Gaps in a line mean no sample was recorded for that bucket, not zero usage.

  • Memory near the limit with lag spikes: raise the server’s memory (ask your administrator) or reduce view distance, plugins, and loaded chunks.
  • CPU pinned at 100%: a single-threaded game (like Minecraft) saturates one core; spread load or upgrade the node allocation.
  • Disk climbing steadily: logs and backups accumulate — prune logs/ and old backups (backups).
  • Compare against quiet hours: if usage is high with zero players, something (a farm, a runaway task, a leak) is burning resources.
  1. Open the server’s Alerts tab.
  2. Select Create Rule.
  3. Details: give the rule a Rule name and optional Description, choose a Rule type, and confirm the Target. On a server page the target is fixed to that server.
  4. Conditions: set the thresholds for the rule type:
    • Resource threshold — CPU threshold (%), Memory threshold (%), and Disk threshold (%). Leave one blank to ignore it.
    • Node offline — Offline threshold (minutes).
    • Server crashed — no threshold; the rule fires on a crash event.
  5. Notifications: add Webhook URLs (a Discord webhook URL is a common choice), Email recipients, and optionally tick Notify server owner. Set the Cooldown (minutes) — the minimum gap between notifications from the same rule (default 5).
  6. Select Create rule.

Resource thresholds are checked against the most recent metrics sample: the rule fires as soon as a reading is over the threshold, and the cooldown stops it from re-notifying on every check. The Alert history section lists incidents with their severity, the rule that fired, any delivery result (for example a failed webhook), and a Resolve button. Use the filter to show Unresolved, Resolved, or All.

Alert fatigue is real: alert on symptoms that need action (offline, disk nearly full), not on every wiggle.

  • Alerts tab (this page) — rules and incidents scoped to one server.
  • Admin → Alerts — administrators see every rule and incident with its target (Global, Server, or Node), an overview count, and Resolve all.