Event Alert Rules
Event alert rules notify you when your server reports a matching event: a TPS drop, a ban, an operator granted. They are checked as soon as the event arrives: the in-app notification is immediate, and email and Discord messages follow within about a minute.
How They Work
Plugin detects a TPS drop
โ POST /api/v1/monitoring/events
โ voxelbench.com stores the event
โ Checks all enabled event alert rules for this server
โ Rule matches โ history entry and in-app notification, right away
โ email and Discord messages queued, sent within a minute
โ Response includes: alerts_dispatched: 1
The matching and the in-app notification happen in the same request that delivers the event. Email and Discord messages go through the same delivery queue as metric alerts, which a background job empties every minute, with retries. Only events sent by the server are matched: the events that voxelbench.com adds itself (metric alerts, maintenance, regression) never trigger an event rule.
Creating an Event Alert
In the side menu, open Monitoring, then your server, then the Alerts tab. In Event Alert Rules, click Add Alert Rule: the Create Event Alert window opens.
Configuration
| Field | Description | Example |
|---|---|---|
| Alert Name | Human-readable name | "Critical Alerts" |
| Event Type | Match a specific type, or All; Custom type... lets you type one | tps_drop, ban, or All |
| Category | Match a category, or All | performance, moderation, or All |
| Source | Match a source, or leave any | voxelbench, litebans, or any |
| Minimum Severity | Minimum severity threshold | Info, Warning or Error |
| Cooldown (minutes) | Minimum time between notifications, from 5 minutes to 24 hours (the form suggests 5) | 5 |
| Notification Channels | Where to send: Email, Discord Webhook, In-App (in-app only by default) | In-App, Discord |
Matching Logic
A rule matches an event when ALL specified criteria are met:
- Type: if set, event type must match exactly
- Category: if set, event category must match exactly
- Source: if set, event source must match exactly
- Severity: event severity must be โฅ the minimum (
info<warning<error)
Setting a field to "All" / "any" means it matches anything. The events the plugin sends, with their category and severity, are listed in Server Events.
Example Configurations
"Notify me of all critical issues"
- Type: All
- Category: All
- Source: any
- Min Severity: Error
- Channels: Email + Discord
โ Catches: tps_critical and memory_critical, the plugin's error-severity events
"LiteBans sanctions"
- Type: All
- Category:
moderation - Source: any
- Min Severity: Warning
- Channels: Discord
โ Catches: ban and tempban from LiteBans (mutes, kicks and unbans are info). Needs the LiteBans integration turned on, and an Enterprise plan or a hosting provider account
"Performance warnings from VoxelBench"
- Type: All
- Category:
performance - Source:
voxelbench - Min Severity: Warning
- Channels: In-App
โ Catches: tps_drop, tps_critical, gc_major, memory_high, memory_critical, player_count_full
"Operator and whitelist changes"
- Type: All
- Category:
security - Source: any
- Min Severity: Warning
- Channels: Discord + Email
โ Catches: player_op, and a whitelist turned off. With the minimum at Info, it also catches player_deop, the other whitelist changes and config_reload
Cooldown
After a rule triggers, it won't trigger again for the configured cooldown period (5 minutes to 24 hours). This prevents notification spam when many events arrive quickly (e.g., TPS dropping again and again during a lag spike).
Matching events silenced by the cooldown are counted: the next notification says how many (for example "(+12 more matching events since the last alert)"), and the alert history shows it ("+12 silenced by cooldown").
Maintenance and mute
During a server maintenance window, or while the rule is muted (bell icon), matching events are still recorded in the alert history, marked as silenced โ nobody is notified. An event is a moment: it is not notified afterwards when the silence ends.
History and delivery
Every time an event rule triggers, it is recorded in the alert history (Event alerts filter) with the event that matched and what each channel did. Emails and Discord messages are delivered through the same queue as metric alerts, with retries. The Send a test notification button sends a clearly labelled fake event on the rule's channels, without recording anything.
Metric Alerts vs Event Alerts
| Metric Alerts | Event Alerts | |
|---|---|---|
| Trigger | Cron checks metrics every minute | When a matching event arrives |
| Latency | 1 minute, plus the plugin's sending interval | In-app: under a second; email and Discord: about a minute |
| Best for | Sustained conditions (TPS low for 3 min) | Discrete occurrences (ban, server stop, operator change) |
| Detection | voxelbench.com analyses the metric data | The plugin detects and reports |
| Config | Metric + condition + threshold + duration | Type + category + source + severity |
| Max rules | Shared, metric and event rules together: 3 per server on Pro, 999 on Enterprise, 10 on a hosting provider account | Same shared limit |
Use both together for comprehensive coverage: metric alerts for sustained performance issues, event alerts for immediate notifications on specific occurrences.