Configuration

Every key in the PulseNode plugin config, plus what is configured in the dashboard instead.

PulseNode v5.0.2Paper · Spigot1.21 – 1.21.x

The plugin config is deliberately small. Anything that is a preference rather than a connection detail lives in the dashboard, so you can change it without touching the server.

The full file

plugins/PulseNode/config.yml

api-url: "https://pulsenode.tech"api-key: "YOUR-API-KEY-HERE" # Collection interval in seconds (minimum 10, default 30)interval: 30 # Send plugin CPU data (requires Spark plugin for accurate data)track-plugins: true # Capture SEVERE console errors and send to PulseNodetrack-console-errors: true # Critical TPS threshold for instant alertscritical-tps: 15.0 # Security Monitoringsecurity:  enabled: true

Key	Default	What it does
`api-url`	`https://pulsenode.tech`	The API endpoint. Only change this if you are told to.
`api-key`	—	Identifies one server. Never share a key between servers.
`interval`	`30`	Seconds between snapshots. Minimum 10.
`track-plugins`	`true`	Per-plugin CPU. Accurate with Spark, estimated without.
`track-console-errors`	`true`	Captures `SEVERE` console lines.
`critical-tps`	`15.0`	Below this, an instant alert fires and a lag snapshot is captured.
`security.enabled`	`true`	Dangerous-command, connection-flood and failed-login tracking.

Apply changes with /pn reload.

Choosing an interval

YAML

interval: 30

30 seconds is right for almost everybody. The trade-off:

Lower (10–20s) — finer resolution on short spikes, more requests, more history rows consumed against your plan's retention.
Higher (60s+) — lighter, but a 40-second lag spike can fall entirely between two samples and never appear in a chart.

Below 10 is rejected. Collecting faster than that costs more in overhead than the extra resolution is worth.

critical-tps

YAML

critical-tps: 15.0

Two things happen when TPS drops below this:

An instant alert is sent, rather than waiting for the next report.
A lag snapshot is captured — the full state at that moment: TPS, MSPT, entity and chunk counts per world, and who was online.

The snapshot is the valuable part. It is the difference between "TPS dropped at 20:14" and "TPS dropped at 20:14 with 11,400 entities in world_nether and these six players online".

Tune it to your server, not to 20

On a busy modded-adjacent server sitting at 17 TPS all evening, a threshold of 15 fires constantly and you stop reading the alerts. Set it slightly below your normal floor so it means something.

What gets sent

Every interval:

TPS, MSPT, RAM used and max, uptime
entity count, loaded chunks and size on disk, per world
player count and the names of who is online
with track-plugins, per-plugin CPU
with track-console-errors, captured SEVERE lines
with security.enabled, queued security events
when TPS is below critical-tps, a lag snapshot

Plus periodic snapshots of plugin and server configuration, which is what lets a report point at view-distance instead of just showing you a chart.

Redaction

Configuration snapshots are filtered in the plugin, before transmission. Any key matching these is redacted:

TEXT

password   secret   token   key      api-keyapikey     api_key  credentials      authmysql      database jdbc     connection-stringwebhook    license

Your database credentials, webhook URLs and licence keys never leave the machine.

Dashboard-side settings

Configured at pulsenode.tech, not in the file:

Setting	Where
Report frequency and recipients	Server → Reports
Alert thresholds and channels	Server → Alerts
Discord channel binding	Server → Integrations
Data retention	Determined by your plan
API access tokens	Account → API (Business)

This split exists so that changing who gets a report does not require SSH access to a game server.

Turning things off

YAML

track-plugins: falsetrack-console-errors: falsesecurity:  enabled: false

All three are safe to disable individually — the rest keeps working. security.enabled: false also removes the /pn security GUI, which will report that security monitoring is disabled.