Monitoring & Integrations

Performance Monitor

Watches TPS and MSPT, and applies graduated optimization levels. A level triggers when either signal crosses its threshold.

monitor:
  enabled: true
  check-interval: 5
  startup-delay: 60
  levels:
    - tps: 18.0
      mspt: 45.0
      actions:
        reduce-mob-spawn-rate: true
    - tps: 16.0
      mspt: 50.0
      actions:
        reduce-view-distance: true
        reduce-simulation-distance: true
        reduce-activation-range: true
      view-distance: 6
      simulation-distance: 6
      activation-range: 16
      tracking-range: 32

Startup grace period

TPS and MSPT are meaningless while worlds load and plugins start, so startup-delay holds evaluation back for that long. Measurements are still taken during the grace period — only the actions wait. That way the first evaluation is based on a settled reading rather than on values still converging from their starting point.

Sustained degradation alert

The levels react to the instant; this reacts to the duration. One notification fires when the server stays under threshold for long enough, to staff and to Discord:

monitor:
  alert:
    enabled: true
    tps: 12.0
    mspt: 50.0
    duration-seconds: 300

Load forecast

Acting when the server is already struggling is acting late. The monitor keeps a trend over the last sixty samples, fits a slope to it, and warns when the current direction would cross the first optimization level within the horizon.

monitor:
  # Nothing is measured for this long after a start, while chunks and plugins settle.
  startup-delay: 180
  forecast:
    enabled: true
    horizon-seconds: 30

The warning is a warning, not an action: nothing is throttled on a forecast alone.

History

TPS and MSPT are already measured every second; keeping them costs a float pair per sample. A full day at one sample per ten seconds is 8 640 entries, held in a fixed ring that never grows. It feeds GET /api/xantilag/history and the dashboard charts.

Diagnostics

The web dashboard answers the first question anyone asks when the server stutters: not "is a limiter switched on" but what is this server actually carrying right now.

• TPS and MSPT with their five-minute peaks, charted over the retained history
• Memory, uptime, players online, active optimization level
• Per-world chunk, entity and tile-entity counts
• The heaviest loaded chunks, with coordinates

Collection is asynchronous and bounded — chunks are read on their own region thread, capped in number, and a timeout releases the result with whatever came back. Opening the page on a struggling server does not make things worse.

Console Logging

A detector that fires several times a minute buries everything else in the log. Each one is silent unless you name it, and its line goes to the debug channel instead.

console-logging:
  chunk-load-watcher: false
  anti-chunkloader: false
  redstone-clock: false
  lag-machine: false
  afk-machine: false
  chunk-limits: false
  stuck-chunks: false

These control the console only. What staff are told in-game is separate, and each detector has its own notify-staff setting, so you can keep a quiet console and still be told in chat. Turn a line on while you are tuning a threshold, then turn it back off.

Discord Notifications

Performance levels, sustained alerts, cleanups, chunk limits, redstone clocks and AFK machines can be pushed to a webhook.

discord:
  enabled: false
  webhook-url: ""
  username: "XAntiLag"
  rate-limit-per-minute: 20
  events:
    performance-level: true
    performance-alert: true
    clearlag: false
    chunk-limit: true
    redstone-clock: true
    afk-machine: true

What goes out is capped by a sliding one-minute quota. Beyond the quota, messages are dropped rather than queued: a burst of events during a lag spike must not become a backlog that arrives long after anyone could act on it.

Sending itself is XCore's job, shared with every addon. A webhook that answers "too many requests" is left alone for as long as Discord asks, and the message goes out afterwards instead of being lost.

Web Dashboard

XAntiLag registers a module with XCore's web panel exposing JSON endpoints for remote monitoring.

Four pages: Status, Performance (TPS and MSPT history), Load (entities and loaded chunks over time — TPS says the server is struggling, these say what with) and Heatmap, which draws the busiest world from above. The heaviest-chunks table answers which one; it never shows that forty of them are the same farm. Coordinates are grouped until the grid fits, so clusters are visible at a glance.

• Token auth — Same Bearer token as XCore's web panel
• Rate limiting — 30 requests per minute per IP
• Folia-safe — Chunk endpoint samples each chunk on its owning region thread

Developer API

Every anti-lag measure in one plugin fights the same problem alone. The plugins that actually generate the load — cosmetics spraying particles, animated menus redrawing on a timer, schedulers hammering — have no idea the server is struggling, so they keep going exactly when they should not.

repositories {
    maven { url 'https://jitpack.io' }
}

dependencies {
    compileOnly 'com.github.Xyness:XAntiLag-API:1.1.0'
}

// State, at any moment, from any thread
if (XAntiLagProvider.isRegistered() && XAntiLagProvider.get().isUnderLoad()) {
    return; // skip the particle burst
}

// Or react only when it changes
@EventHandler
public void onLoad(PerformanceLevelChangeEvent event) {
    particlesEnabled = event.isRecovery();
}

PlaceholderAPI