AI reports

The reports are the point of PulseNode. Charts tell you that something happened; the report tells you what it was and what to change.

Frequency

Delivered by email, and to your Discord channel if you have connected one. Recipients and frequency are set under Server → Reports in the dashboard.

What a report contains

A verdict, first. Whether the week was better or worse than the last one, in one sentence.

Performance summary. Average and worst TPS/MSPT, when the worst moments were, and how they compare to the previous period.

Correlations. The part that takes a human hours to do by hand: the recurring pattern behind the drops. Same time every day? Same player online? Rising with entity count in one world?

Lag snapshots. Each captured drop with the state at that moment, so you are reading facts rather than reconstructing them.

Console errors. Grouped by signature with counts, worst first — a stack trace repeating 4,000 times appears once with a number, not 4,000 times.

Actionable tips. Concrete changes, referencing your actual configuration. Not "consider reducing entities" but "world_nether averages 9,400 entities against 1,200 in world; your spawn-limits.monsters is at the default 70 with view-distance: 12".

Security summary on plans that include it: dangerous commands, connection floods, failed logins.

How the tips are produced

The pattern detection is ordinary analysis on the time-series data — that part is arithmetic, not AI. What the model does is turn the findings and your configuration snapshot into readable prose with a recommendation.

That split matters for trust: the facts in a report come from your data, deterministically. The wording and the prioritisation are generated.

What data the report sees

Everything the plugin sent for the period:

• the metric time series
• lag snapshots
• captured console errors
• security events
• plugin and server configuration snapshots

Configuration snapshots are what let a tip name view-distance or spawn-limits instead of speaking in generalities.

Secrets are redacted in the plugin, before transmission — keys matching password, secret, token, key, credentials, mysql, database, jdbc, webhook, license and similar never leave your machine, and therefore never reach a report.

Making reports more useful

Install Spark. Per-plugin CPU is the single most actionable data point there is, and without Spark it is an estimate. With it, a report can name the plugin.

Keep track-console-errors on. Errors explain drops that metrics alone cannot.

Give servers recognisable names. A report about "Server 3" is harder to act on than one about "survival".

Set critical-tps to a threshold that means something on your server. If it fires constantly, every report is full of snapshots and none of them stand out.

Reading your first report

The first report on a new server will be thin — a week of history is barely a sample, and the correlations need repetition to appear. The third report is where PulseNode starts being worth its subscription, because that is when "every evening at 19:00" becomes visible as a pattern rather than as three separate incidents.

Crash analysis

Pro and Business include crash analysis: when a server stops posting and then restarts, the last snapshots before the gap are pulled together with whatever console errors were captured, so the report can say what the server was doing as it went down.