Alerts
Alerts watch your servers and tell you when something breaks or slips. Each alert carries the scope, window, and comparison behind it, so the first question is already answered.
How alert rules work
Section titled “How alert rules work”An alert rule watches one signal over an evaluation window and fires when the condition holds. Rules move through IDLE → FIRING → RESOLVED; they resolve when every server in scope clears the condition, and a cooldown prevents immediate re-firing.
| Field | Rules |
|---|---|
| Signal | One of the supported measures below. |
| Operator and threshold | gt, gte, lt, or lte against a numeric threshold. |
| Servers | Empty means every server; up to 50 servers can be selected. |
| Evaluation window | 1–60 minutes. Default 5. |
| Cooldown | 1–1440 minutes. Default 15. |
| Channels | In-app, email, or Discord. Default in-app. |
Supported signals
Section titled “Supported signals”tps_avg, mspt_avg, cpu_usage_avg, memory_usage_avg, player_count_avg, unique_players, total_sessions, and total_events.
Delivery channels
Section titled “Delivery channels”Channels are configured once at the organization level and then selected per rule:
| Channel | Delivery |
|---|---|
| In-app | A notification in the dashboard, with a live stream of monitoring events. |
| A per-server breakdown of what fired. | |
| Discord | A rich embed in the channel behind your webhook. |
A rule that references a channel which has not been configured is skipped, so set up channels before relying on a rule. Delivery attempts are recorded with a status (DELIVERED, FAILED, RETRY_SCHEDULED, and others), attempt counts, and failure reasons; failed deliveries can be retried from the dashboard.
Investigations
Section titled “Investigations”Open an alert evaluation to see why it fired:
- The metric summary and threshold that was crossed.
- Correlated metrics over the same window.
- Related logs and a timeline of events.
- Version or configuration changes near the window.
- Lifecycle actions for the alert.
Suggested thresholds
Section titled “Suggested thresholds”These starting points match the platform’s own health bands. Tune them for your network.
| Metric | Warning | Critical |
|---|---|---|
| TPS | below 19 | below 17 |
| MSPT | above 40 ms | above 50 ms |
| CPU | above 70% | above 90% |
| Memory | above 75% | above 90% |
| Latency | above 100 ms | above 200 ms |
Uptime and recovery
Section titled “Uptime and recovery”Configure an alert on server reporting so staff hear when a server stops sending data and again when it recovers. Pair the firing rule with the recovery state so the channel gets a closing message rather than a permanent alarm.
Rules can be organization-wide or scoped to a single server. Server-scoped rules live under the server’s Alerts page; organization rules live under Alerts in the main sidebar.