Command Manager Guide

What the Command Manager is for

The Command Manager runs console commands on your server for you, on a repeating schedule. An hourly world save. A restart warning at the same time every night. An item for everyone who happens to be online on a Friday.

You pick a command from a list, fill in its parameters, choose when it should run, and save. Nothing stays open on your computer, and you only write a cron expression if you would rather.

It is one of two tabs on the Event Manager page. The other, Config Events, changes settings files and restarts the server for a while - a 2x XP weekend. The Command Manager sends console commands and restarts nothing.

Windrose is the one to read about before planning anything. It has no broadcast, say or chat command of any kind, so no Windrose schedule can put a message in front of players. See Windrose Command Manager.

Your first schedule

Two minutes, and nothing you can break:

1. Open your server, click Event Manager, then the Command Manager tab.

2. Click + New Schedule (or Create Your First Schedule if the list is empty).

3. Name it Hourly Save.

4. Pick Save World from the command dropdown.

5. Under the schedule picker, choose Hourly.

6. Read the sentence it shows you - "Every hour at minute 0" - and the next five runs beneath it.

7. Click Create.

8. Click Run Now on the new card, then Log, and see what your server said back.

Step 8 is the habit worth forming. Run Now then Log tells you whether a schedule works in ten seconds instead of at 4am tomorrow.

What your game can do

The command list is per game, and so is the way "everyone online" works.

Each game article covers the commands it actually has, what behaves differently on a schedule, and the schedules worth building on it. This page covers the parts that are the same everywhere.

The form, field by field

A live preview of the finished command sits under the parameter fields, so you can read exactly what will be sent before you save.

Under the schedule picker the page shows what you built as a sentence - "Every Monday and Thursday at 4:00 AM" - and the next five times it will fire, each in the schedule's timezone and in UTC. Those are worked out by the server that will run the schedule, not by your browser, so they stay right across a daylight-saving change.

Choosing when it fires

The cron expression is shown next to the plain-English description whichever way you build it, so you can check both before saving.

Limits: nothing may fire more often than every 5 minutes, and a server may hold up to 50 schedules.

Several commands in order

Switch Schedule Type to Multi-Step and you get an ordered list of steps - up to 20, all sharing one cron schedule and one timezone.

Each step has its own command, its own parameters, and its own Send to every online player toggle. Use the arrows to reorder, Remove to delete one, + Add Step to add another.

Every step after the first also has a Wait box: how long to pause before that step runs, up to one hour. That is what turns a list of commands into a maintenance sequence.

A restart nobody can complain about

One cron trigger, five steps, and the warnings cannot drift away from the restart they are warning about. Five separate schedules would need their times kept in step by hand forever.

Steps run in order. Each one is logged on its own row with its step number, plus a schedule-level summary row. If a step fails the sequence continues to the next one, and the overall status is recorded as an error.

A sequence that waits is still running while it waits. Four steps spanning half an hour really can still be going when the schedule next comes due - which is what the overlap policy below is for.

Run this - when a firing is allowed

A run that a condition turns away is recorded as skipped - not a success, and not a failure.

It appears in the history with the reason in plain words: "Skipped: nobody was on the server. This schedule is set to run only when players are online."

It does not count towards the missed-run tolerance, because the schedule did exactly what you told it to.

If the player list cannot be read at that moment, the schedule runs anyway. That direction is deliberate: a broadcast into an empty world costs nothing, and a nightly save that silently stopped happening because a player-count check was flaky costs a world.

Alerts

Tick Alert me when this schedule fails to have failures flagged. Alerts are off unless you turn them on, and the setting is per schedule.

Be clear about that last row: it does not email you or message you in Discord. Where you notice a problem in practice is the panel. If you want failures pushed to you, the webhook is the way - see Webhooks.

Reliability settings

Collapsed by default, and every setting inside has a working default. Open it if you run more than one server, or if a schedule does something that must not happen twice.

Why each one exists

Reaching everyone online

For a command that targets a player - give, kick, teleport, buff - an Send to every online player checkbox appears beside the player field. Tick it and you type no names and no IDs at all. When the schedule fires we read who is on the server and send the command accordingly.

The 7 Days to Die row is worth knowing even if you never tick the box. The console splits a command on spaces:

buffplayer Bob Smith buffFoo

That is read as buffing a player called "Bob" with a buff called "Smith". An entity ID is digits and cannot be misread, so if you target one player by hand there, use the ID from listplayers.

Windrose has no numeric handle at all - wp.players returns names and nothing else. Multi-word Windrose names do work: send them unquoted. Quotes make it worse, because Windrose Plus treats them as part of the name it is looking for.

The second row is deliberate. 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.

This is not the same as {playerNames}

The two get mixed up constantly and they do opposite things.

Giving every player an item is the checkbox. Announcing who is online is the variable. They do not interfere, so one schedule can use both.

Variables in text

Under every text box is a row of chips: Players online, Player names, Server name, Time, Date, Next run, One of these, Random number.

A chip inserts a placeholder, not a value. Clicking "Players online" types {players} into the box. It does not paste today's number in. The real value is filled in when the command is sent.

Values are worked out per step, at the moment that step runs - so in a sequence that waits twenty minutes between steps, a count read by step 1 and a count read by step 5 are both current.

Restart at {nextRun} - {players} online, save your progress

That goes out carrying the real next-run time and the real player count, every time, and stays correct if you move the schedule.

Full reference, including what happens when a value cannot be read: Command Manager Variables.

Managing schedules

Each card in the list shows the name, the exact command that will be sent, the schedule in plain English and as cron, the timezone, the next run, whether it is enabled, and its last run's status.

If you only want a schedule to stop firing, disable it rather than deleting it. The schedule and its history stay, and one click brings it back.

Reading the history

Click Log for the last 50 executions. Each row carries the exact command that was sent, the server's output, any error, and a status. Multi-step runs are numbered.

The command on a log row is what actually went to the server, not the template stored on the schedule - variables already resolved, and one row per player on an Send to every online player step. A message that went out with {players} still in it, or a player name split on a space, is visible immediately.

About "Sent, unconfirmed"

Minecraft's console returns no reply. It confirms that a command reached the game's input and nothing more, so a command the server accepted and one it threw away produce the identical empty response. Minecraft steps are therefore recorded as "Sent, unconfirmed" in amber rather than given a green tick they cannot earn.

Games with a real reply channel - 7 Days to Die telnet, the Palworld REST API, the Valheim bridge, the Windrose Plus dashboard - still show Success with the server's own output beneath it.

A failed run is not retried. It waits for the next firing, or for the catch-up window if the reason was that we could not reach your server at all.

Every status and what to check: Command Manager Troubleshooting.

Timezones

When you open the Event Manager your browser timezone is detected and synced to your profile, and every time in the Command Manager is shown in it.

A new schedule defaults to that timezone. You can change it to any IANA name - America/New_York, Europe/London, Asia/Tokyo - and the cron expression is then read in the timezone you chose.

Built schedules before September 2026? The timezone you picked was saved but never read when the schedule fired, so everything ran on UTC. That is fixed - a schedule set for 04:00 America/New_York now fires at 04:00 in New York. If you worked around it at the time by shifting the hour, the schedule is now wrong by the amount you shifted it. Open it, put the intended time back, and check it against the "next five runs" preview.

Recipes worth copying

Scheduling a shutdown stops the server and nothing brings it back on its own - everyone is disconnected until you press Start. If you want a nightly *restart*, use Automatic Daily Restart instead.

Long-standing faults fixed in September 2026

If your schedules predate September 2026, these are worth going back over.

The same schedules, elsewhere