Metric Alert Rules

How They Work

A background job checks every enabled rule once a minute against the samples your server sent. The plugin sends its samples in batches, so the rule's window is counted back from the latest sample received, not from the current time.

Backend cron (every minute)
  → For each rule, take the samples of the last N minutes (counted back from the latest one)
  → Every sample crosses the threshold          → trigger (notify once)
  → The 3 latest samples are healthy           → resolve
  → Anything else (gap, mixed values, no data) → keep the current state

To trigger, the window must hold at least 3 samples when the duration is 3 minutes or more (1 below that). When the latest sample is more than 10 minutes old, nothing is decided. TPS and MSPT rules ignore the samples taken while Minecraft had paused an empty server.

Missing data never resolves an alert: a server that stops sending keeps its alerts open, and it is the Server Offline rule that tells you it went silent.

Creating a Rule

In the side menu, open Monitoring, then your server, then the Alerts tab. In Alert Rules, click Add Alert Rule: the Create Alert Rule window opens.

Configuration

Available Metrics

The Server Offline metric is special: it triggers when no heartbeat has been received for the configured duration (3 minutes minimum), and it needs neither a condition nor a threshold. A server that has never sent a heartbeat does not trigger it — the setup assistant covers that case, and offers to create this rule in one click (Create the offline alert: 5 minutes, by email and on the site). Offline rules also wait instead of raising false alarms when the problem is likely on VoxelBench's side: when no monitored server at all is heard from, or when more than 30 % of them (at least 3) go silent within the same minute. This pause lasts 30 minutes at most.

RAM is measured in megabytes: for "RAM above 90 %" on a 16 GB server, use a threshold of about 14 700 MB.

Notification Channels

In-App

A notification appears in your notification bell on the website. Always available.

Email

An HTML email is sent to your account email with alert details, metric values, and a link to the dashboard.

Discord

If your server has a Discord webhook (server settings, Notifications tab, Discord Webhook URL field, shown whether Notify on new report is on or not), an embed message is posted to that Discord channel. If you connected your personal Discord in your account settings (Profile & settings → Notifications), you also receive a copy of every alert of a rule that notifies at least one channel.

Delivery and retries

Email and Discord notifications go through a delivery queue: if the mail server or Discord is briefly unavailable, the notification is retried (after 1 minute, 5 minutes, 30 minutes, then 2 hours) instead of being lost, and abandoned after the fifth attempt. A Discord webhook that no longer exists or refuses the message (401, 403, 404, 410) is not retried. Each alert in the history shows what every channel did: delivered, retrying, skipped (unsubscribed, no webhook) or failed.

Test a rule

The Send a test notification button (paper plane) next to each rule sends its message now on its channels, prefixed with [TEST], and tells you which channels received it. A test writes no history and does not start the rule's cooldown. You can send 5 tests per 10 minutes, metric and event rules together.

Maintenance and mute

Planned work should not page you. Three ways to keep quiet, none of which stops the evaluation — alerts are still recorded in the history, marked as silenced:

• Maintenance — at the top of the server's monitoring dashboard, Maintenance silences every alert of the server for 15 minutes to 24 hours. The window ends on its own; you can end it early (End maintenance) or Extend it. It also exists in the API (/servers/{id}/maintenance, 5 to 1,440 minutes) and for AI agents (start_maintenance, end_maintenance).
• Mute a rule — the bell icon next to a rule (Mute this rule) silences it for 1, 4 or 24 hours. Unlike the switch, it does not pause the rule nor close its alerts. A paused rule cannot be muted.
• Announced stops — when the plugin reports that the server is stopping, the Server Offline rule waits its own duration plus 30 minutes, counted from the announcement, before alerting: a planned restart does not page you, a server that does not come back still does. When you run /bench monitor remote off, the silence is intentional and the rule does not fire.

If a threshold alert is still firing when the silence ends, it is notified at that moment — a server still broken after maintenance does not stay silent.

Alert Lifecycle

1. Triggered — Every sample of the window crossed the threshold; notifications are sent once.
2. Acknowledged (optional) — You marked it as seen (Acknowledge). It stays open and is not notified again until it resolves.
3. Resolved — The 3 latest samples are healthy again: a "Resolved after X min" notification goes to the same channels as the alert. Or the rule stopped being evaluated: paused, monitoring turned off, plan no longer including monitoring, or server over your plan's quota. The history shows which.
4. Cooldown — After an alert, the same rule does not trigger again before the cooldown has passed.

Pausing a rule keeps it exactly as it was — channels, duration and cooldown — and closes its open alerts.

Alert History

Alerts in progress are listed above the dashboard's tabs, under Active Alerts, where you can Acknowledge them. In the Alerts tab, the Alert History section shows all past alerts, which you can filter (All, Triggered, Resolved, Acknowledged, Event alerts), with:

• Rule name and metric
• Condition vs actual value
• Status (triggered / acknowledged / resolved) and why it resolved
• When triggered and when resolved
• What each notification channel did

Resolved alerts are kept for 90 days.

Limits

The limit counts metric and event rules together. The Alerts tab shows how many your server uses.