Command Manager Troubleshooting
What every execution status means, why a schedule fired late or not at all, why a give-to-everyone reached nobody, and the per-game checks for all five games.
Start with the log
Almost every question about a schedule is answered by its own history. Open the Command Manager tab, find the schedule, click Log. You get the last 50 executions.
The command on a log row is what actually went to your server - variables already resolved, and one row per player on an all-players step. Not the template stored on the schedule. If a message went out with
{players}still in it, or a player name arrived split in half, the row shows it.
That single field settles most problems before you read any further.
What each status means
| Status | Meaning | A problem? |
|---|---|---|
| Success | Sent, and the server replied | No |
| Sent, unconfirmed | Delivered to a console that carries no reply | No |
| Error | Not delivered, or the server rejected it | Yes |
| Skipped | A run condition turned this occurrence away | No - it did what you asked |
| Missed its run | Has not fired for longer than you allowed | Yes |
Sent, unconfirmed
Normal on Minecraft, and honesty rather than a fault. Minecraft's console is a one-way pipe: we can write a command into it and confirm the write succeeded, but the game returns nothing. A command that worked perfectly and one that was thrown away produce the identical empty response.
So the row says what we actually know. To confirm a scheduled Minecraft command did what you wanted, look at the game.
Games with a real reply channel - 7 Days to Die over telnet, Palworld's REST API, the Valheim bridge, the Windrose Plus dashboard - still show Success with the server's own output underneath.
Skipped
A run condition doing its job. The row carries the reason in plain words: "Skipped: nobody was on the server. This schedule is set to run only when players are online."
It is neither a success nor a failure, and it does not count towards the missed-run tolerance. If you did not expect it, check Run this on the schedule - most often it is set to "Only when players are online", or has a minimum player count you have forgotten about.
Missed its run
The schedule has missed more consecutive runs than its tolerance allows, and its card turns orange. It is a state of its own, sitting before any individual failure, because a schedule that has quietly stopped firing is the failure people notice last.
Editing the schedule clears the flag, so something you have just fixed stops reporting itself as broken.
It did not run at all
Work down this list in order.
| # | Check | What you are looking for |
|---|---|---|
| 1 | Is it enabled? | A disabled schedule stays in the list and never fires. The badge reads Disabled in grey |
| 2 | The next run time on the card | If it is not what you expect, the schedule is not what you think it is |
| 3 | The timezone on the card | 04:00 fires at 04:00 *there*, which may not be where you are |
| 4 | Was the server reachable? | A run we could not deliver still happens up to the catch-up window afterwards - 15 minutes by default |
| 5 | Was the previous run still going? | The default overlap policy is Skip, which drops the occurrence on purpose |
For step 2, read the plain-English sentence on the card rather than the cron expression. For step 3, open the schedule and use the "next five runs" preview, which shows each firing in both the schedule's timezone and UTC - and is worked out by the server that will run it, so it stays right across a daylight-saving change.
For step 5: a multi-step sequence with waits in it can legitimately still be running when it next comes due. Skipping is usually what you want, because two overlapping restarts is a corrupted world, but it does mean an occurrence went missing deliberately. The Reliability section is where you change it.
Built it before September 2026? Timezones were stored but never read, so every schedule fired on UTC whatever it said. That is fixed. If you worked around it at the time by shifting the hour, the schedule is now wrong by exactly the amount you shifted it - put the intended time back and check the preview.
It ran, but nothing happened in the game
| Symptom | Likely cause |
|---|---|
| Minecraft row reads "Sent, unconfirmed" | Expected. The command reached the console; the game said nothing back |
| A player command did nothing | The target was not online. Nearly every player command needs its target connected at that moment |
| The command in the log looks wrong | Read it carefully - this is the fastest diagnosis available |
| A custom command did nothing | The syntax was not checked before sending. Compare it against the game's console |
On that third row: if the log reads buffplayer Bob Smith buffFoo, the console read that as buffing a player called "Bob" with a buff called "Smith". The command was split on the space in the name.
On Minecraft specifically, a silent no-effect is usually a misspelled item ID, a player who had already logged off, or a plugin command sent through Custom Command with the wrong syntax.
A give-to-everyone reached nobody
Open the log first. An Send to every online player step produces one row per player on every game except Minecraft, each naming the player it ran for.
| What the log shows | Means | Do |
|---|---|---|
| No rows, run recorded as a no-op | Nobody was online | Nothing. This is not a failure |
| An error saying the player list could not be fetched | The roster could not be read, so nothing was sent | Read the error - it names the channel that failed |
| One row per player, all errors | The roster read fine; the command is wrong | Check the item or buff name, and the identifier |
| One row only, on Minecraft | Normal - @a is a single command | Nothing |
Nothing is sent when the roster is unreadable, and that is on purpose. An empty server and an unreachable one look identical from a distance, and treating the second as the first is how a giveaway reports success having given nothing to anybody.
The form will not let me save
| Message | Means |
|---|---|
| Minimum schedule interval is 5 minutes | Nothing may fire more often than every 5 minutes |
| Maximum 50 schedules per server | Delete or disable something first |
| Custom command exceeds 500 characters | A custom command string has a 500-character ceiling |
| An invalid cron expression | The preview shows the reason. Use the schedule buttons rather than writing cron by hand |
A schedule may hold at most 20 steps, and each step's wait is capped at one hour.
Per-game checks
7 Days to Die
| Symptom | Cause |
|---|---|
| "Connection refused" errors | Commands go over telnet - almost always the server is stopped |
| A scheduled horde wanders instead of hunting | Expected. A wandering horde heads for whoever called it, and a schedule is not a player. It is still a real horde |
| A scheduled screamer is refused | spawnscouts on its own can only be run by a player. Pick Spawn Screamers Near a Player or at Coordinates instead |
| An item giveaway drops nothing | Give Item needs the game's exact item name. listitems in the Console tab prints them |
Minecraft
| Symptom | Cause |
|---|---|
| Everything reads "Sent, unconfirmed" | Expected - the console carries no reply |
{players} works but commands are unconfirmed | Questions go over RCON, which does reply; commands go to the console, which does not |
| A plugin command is missing from the list | All five flavours share one catalog of 24 server commands. Plugin and mod commands go through Custom Command |
Palworld
| Symptom | Cause |
|---|---|
| Every schedule fails | Check `AdminPassword` first. No admin password means no REST API, and Palworld has no console to fall back on |
| A PalDefender command fails | PalDefender is not installed, or its REST API is not enabled |
| A custom command does nothing | Custom is narrower here - it can only reach what the REST API exposes |
Valheim
| Symptom | Cause |
|---|---|
| Every schedule fails | The GameGrid Bridge plugin is not running. Schedule Bridge Health Check to find out when it started |
| Old save schedules look like they were failing | Saves used to be cut off at 15 seconds against an operation that can take 90. Check their recent history - they may be fine now |
| A spawn aimed at one named player fails | Session IDs change on every reconnect. Use Send to every online player, which reads the roster fresh |
Windrose
| Symptom | Cause |
|---|---|
| No way to warn players | Windrose has no broadcast, say or chat command of any kind. That is the game, not a fault |
| "Player 'x' not found" recorded as a failure | The player was not connected when it ran |
| A name with a space does not match | Send it unquoted. Quotes make it worse - Windrose Plus treats them as part of the name |
| Generate Live Map Terrain stopped working | It only works on a fresh boot. On a repeat it succeeds once then quietly achieves nothing |
On that third Windrose row: the read-only player commands are fine with any name. Teleport, Speed, Jump and Gravity take further arguments *after* the name, so there is no way to mark where a multi-word name ends. Prefer the read-only commands on a schedule if your players have spaces in their names.
Where a failure actually surfaces
| Channel | Tells you |
|---|---|
| The schedule card in the panel | Its last run's status, and an orange state when it has stopped firing |
| The Log modal | Every run, with the exact command and the server's reply |
The command_schedule.executed webhook | Every run, pushed to your endpoint, with its status |
| "Alert me when this schedule fails" | Records an alert against the schedule for support to read back |
That last row does not email you or message you in Discord. If you want failures pushed somewhere, the webhook is the way - see Webhooks.
Still stuck
Have these three things ready and support can usually answer in one reply:
1. The schedule name.
2. What you expected to happen.
3. A screenshot of the Log modal showing the rows in question.
The expanded command on a log row is the single most useful piece of evidence there is.
| Also useful | Article |
|---|---|
| The full feature walkthrough | Command Manager Guide |
| The placeholder system | Command Manager Variables |
| Your game specifically | 7 Days to Die · Minecraft · Palworld · Valheim · Windrose |