Alerts & security
Instant TPS alerts, lag snapshots, and the security monitoring that watches operators, connections and failed logins.
PulseNode v5.0.2Paper · Spigot1.21 – 1.21.x
Performance alerts
critical-tps: 15.0When TPS drops below critical-tps, two things happen immediately rather than waiting for the next
report:
- An alert goes out — email, Discord, or both, depending on your alert settings.
- A lag snapshot is captured: TPS and MSPT at that moment, entity count and loaded chunks per world, world sizes, and who was online.
The snapshot is what makes the alert actionable. "TPS dropped" is a notification; "TPS dropped with
11,400 entities in world_nether and these six players online" is a lead.
Setting the threshold
Set it slightly below your normal floor, not at 20.
A server that idles at 19.9 TPS and dips to 18 under load should have a threshold around 16. A server that lives at 17 all evening should be at 14. A threshold that fires every ten minutes trains you to ignore alerts, which is worse than having none.
Offline alerts
The dashboard also notices when a server stops posting entirely, after a grace period of a few intervals. Useful for catching a crash, and for noticing that a scheduled restart took twenty minutes instead of two.
Rate limits
| Plan | Alerts per day |
|---|---|
| Free | 10 |
| Pro | unlimited |
| Business | unlimited |
The cap exists so a flapping server cannot produce hundreds of messages overnight.
Security monitoring
security: enabled: trueSeparate from performance, and separate from anti-cheat. This watches the administrative surface of your server.
Dangerous commands
Commands that change who has power — op, deop, permission changes, stop and similar — are
recorded with the player, the command and a severity.
The severity depends on context: the same command from somebody who was not already an operator is recorded as critical, because that is either an exploit or a compromised account. From an existing operator it is a warning — expected, but worth having in the record.
Connection floods
More than 10 connections from one IP inside 60 seconds is recorded as a flood. This is the signature of a bot attack, and it usually shows up minutes before anybody notices lag.
Failed logins
Failed logins are counted per IP. At 5 from the same address the severity escalates to critical. On an online-mode server, repeated failures from one address are almost always somebody probing.
The in-game GUI
/pn securityOpens a menu with the recent security events, colour-coded by severity. Players only, and it
requires pulsenode.admin.
The GUI shows IP addresses
Grant pulsenode.admin only to staff you would give server-log access to anyway.
What each plan includes
| Free | Pro | Business | |
|---|---|---|---|
| Command log | yes | yes | yes |
| Open-port check | yes | yes | yes |
| Bot detection | — | yes | yes |
| Crash-exploit detection | — | yes | yes |
| Vulnerability scanner | — | yes | yes |
| Suspicious-activity alerts | — | yes | yes |
| Security section in reports | — | yes | yes |
| Failed-login tracking | — | — | yes |
| Permission-change tracking | — | — | yes |
| Security score | — | — | yes |
Turning it off
security: enabled: falseEverything else keeps working. /pn security will report that security monitoring is disabled.
Worth considering if another plugin already covers this ground — running two systems that both log
every op command produces two logs nobody reads instead of one that somebody does.
Privacy
Security events include IP addresses, which your server already records in its own logs. They are transmitted to your PulseNode account and visible only to whoever can sign in to it.
If you publish a privacy policy — and in the EU you should — this belongs under your existing entry for server connection logs, naming PulseNode as a processor.