Servers & events
What the dashboard shows for a connected server.
Once a server is connected with the agent plugin or Pterodactyl, the dashboard becomes its health record.
The server page
Click a server name for:
- Live sparklines: TPS, memory and player counts over the last hour (TPS and player counts need the agent plugin).
- The event feed: errors, crashes, plugin changes, alerts, starts and stops. Repeats of the same error within 10 minutes are collapsed with a multiplier so one broken plugin does not bury everything else.
- Your plugin inventory: every plugin with its version, as last reported.
Diagnosis cards
Errors in the feed come with an expandable diagnosis card: what broke, why, and fix steps, the same format as the Log Doctor. After you try a fix, vote on the card. Votes feed the shared knowledge base that makes future diagnoses faster.
The action center
If your plan includes actions, the server page has an Action center where you enable action classes, watch pending approvals, and read the audit log. Everything is off by default; the safety model explains the guarantees.
The test player
Paid orgs can let a test player join the server as a real Minecraft client: after a fix, on a schedule, or on demand. It checks that the world loads, commands respond, and players can get in. It is off until you turn it on, per server, on the server page. Results are kept for 30 days.
Test commands
The test player only knows the commands you list in the Test commands section on the server page. Your plugins are your own, so nothing else can tell it what arguments /shard takes or what a working reply looks like.
Agent 0.1.4 and newer reads the commands your plugins declare and lists them there under "commands found on your server", so you tick the ones you care about instead of typing a list. Nothing found this way is usable until you turn it on.
The test player also reports what it could see itself. Every time it joins, the server hands it the list of commands that player is allowed to run, so commands registered while the server is running (Skript and similar) get picked up too, and each entry shows whether the test player can actually run it. A command marked usable that the test player could not see is the warning that it lacks the permission, said before a test fails rather than after.
Each entry holds:
| Field | Why it matters |
|---|---|
| Command and aliases | The only names a test is allowed to send |
| Syntax and example | What the test copies instead of guessing at arguments |
| What it does | Lets a plain-English request find the right command |
| Success looks like | The text the test waits for. Without it, a test sends the command and checks nothing |
| Failure looks like | Recognized as a failure rather than a timeout |
| Permission it needs | The test player joins as a normal player with no permissions. If the command needs one, grant it to the test player's account or the server will refuse the command in game |
If you ask for a test that needs a command you have not listed, the test is refused before it runs and names the command to add. Nothing gets approximated.
This list is separate from the action allowlist. That one lets MCTotem run a command as the server to fix a problem; this one lets the test player type a command in chat. Commands on the permanent denylist, such as /op and /stop, cannot be added to either.
Related
Last updated on