7 Days to Die Command Manager
Schedule 7 Days to Die console commands to run on their own - hourly saves, blood-moon warnings, airdrops, giveaways and buffs for everyone online - with all 46 schedulable commands, checked against the running V3.2 server, and the ones that behave differently unattended.
At a glance
| Commands you can schedule | 46 |
| How commands reach the server | Telnet - the same channel as the Console tab |
| Does the server reply? | Yes. Runs are recorded as real successes or failures |
| Commands that target a player | 10 |
| Reaching everyone online | One command per player, by entity ID |
| Can it message players? | Yes - say to everyone, pm to one person |
| Minimum interval | 5 minutes |
The Command Manager runs console commands for you on a repeating schedule. You pick one from a list, fill in its parameters, choose when it runs, and save. Nothing stays open on your computer.
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. The Command Manager sends console commands and restarts nothing.
Telnet answering back matters more than it sounds. The server replies to
saveworldandlistplayerswith real text, so a scheduled run here can be recorded as a genuine success or failure with the server's own output stored beside it. Games with a one-way console cannot offer that.
Your first schedule
1. Open your server, click Event Manager, then the Command Manager tab.
2. Click + New Schedule.
3. Name it Hourly Save.
4. Pick Save World from the dropdown.
5. Choose Hourly under the schedule picker.
6. Click Create.
7. Click Run Now, then Log, and read what the server said back.
Run Now then Log is the habit worth forming. It tells you whether a schedule works in ten seconds rather than at 4am tomorrow.
The 46 commands
Every command here was checked against a running V3.2 server: the list the game itself publishes, and its own help text for each one. A command earns a place only if it works over telnet and has some reason to run unattended. Anything missing can still be sent with Custom Command.
Server
| Command | Sends | Notes |
|---|---|---|
| Broadcast Message | say "…" | Text in front of everyone, from a schedule |
| Message One Player | pm | A private message. They must be online |
| Save World | saveworld | The workhorse. Safe to run hourly |
| Shutdown Server | shutdown | Stops the server. It does not come back on its own |
| Set Game Time | settime | Real risk to timer-based save data - see below |
| Set Temperature Unit | settempunit | Fahrenheit or Celsius |
| Server Version | version | Game version and every loaded mod |
| Memory Info | mem | Memory use, and it runs the collector |
World
| Command | Sends | Notes |
|---|---|---|
| Weather: Reset to Defaults | weather Defaults | Undoes every override below |
| Weather: Rain | weather Rain | 0 to 1, or -1 to hand it back |
| Weather: Snowfall | weather SnowFall | 0 to 1 |
| Weather: Cloud Cover | weather Clouds | 0 to 1 |
| Weather: Fog | weather Fog | 0 to 1 |
| Weather: Wind | weather Wind | 0 to 200 |
| Weather: Temperature | weather Temp | -99 to 101, in the server's unit |
| Weather: Run a Storm | weather Storm | Hours, plus one biome |
| Set Game Preference | setgamepref | Advanced. Read the current value first |
| Set Game Stat | setgamestat | Advanced, same caution |
| Render Map Area | visitmap x1 z1 x2 z2 | Puts ground on the live map nobody has walked |
| Render Whole Map | visitmap full | The lot. Long, and heavy while it runs |
| Render Map: Stop | visitmap stop | Cancels a render in progress |
| Write Map Image to Disk | rendermap | An image file of what has been rendered so far |
Weather is one setting per command, not a single "set the weather" box, because the game takes one setting at a time and each has its own range. Rain is 0 to 1; Temp is -99 to 101; Wind goes to 200. One number field could not be right for all three.
Players
| Command | Sends | Takes |
|---|---|---|
| Kick Player | kick | A player, plus an optional reason |
| Kick All Players | kickall | A reason. Everyone can rejoin afterwards |
| Teleport Player to Coordinates | teleportplayer | A player, an x/y/z triple, and optionally a facing |
| Teleport Player to Another Player | teleportplayer | Two players, both online |
| Buff Player | buffplayer | A player and a buff name |
| Remove Buff from Player | debuffplayer | A player and a buff name |
| Give Item to Player | give | A player, an exact item name, an amount, optionally a quality |
| Give XP to Player | givexp | A player and an amount |
Height -1 on a teleport puts the player on the ground, which is almost always what you want. South and west are negative.
Spawns
| Command | Sends | Notes |
|---|---|---|
| Spawn Airdrop | spawnairdrop | One supply crate, somewhere random |
| Spawn Wandering Horde | spawnwandering h | Wanders. From a schedule there is nobody to hunt |
| Spawn Wandering Bandits | spawnwandering b | Same, with bandits |
| Spawn Screamers Near a Player | spawnscouts <player> | Homes in on the player you name. They must be online |
| Spawn Screamers at Coordinates | spawnscouts <x> <y> <z> | Needs no player - the one to use from a schedule |
| Spawn Entity Near a Player | spawnentity | A player, an entity class name, optionally a count |
| Spawn Entity at Coordinates | spawnentityat | An entity class name and a point. No player needed |
| Kill All Entities | killall | Blank for enemies, alive, or all. Never players |
Spawn things above the ground, not at it. A height of -1 or 0 on
spawnentityatdrops the entity out of the world - the game logs "fell off the world" and nothing appears. 120 is a safe default; they fall in.
Informational - the ones worth scheduling for the record they leave
| Command | Sends | What the history then holds |
|---|---|---|
| List Online Players | listplayers | Who was on, at every interval you chose |
| List Player IDs | listplayerids | Names against user IDs, for identifying somebody later |
| List Known Players | pplist | Everyone the world has ever seen, not just those on now |
| Get Game Time | gettime | The in-game day and time |
| Show Next Horde Time | shownexthordetime | How long until the next blood moon |
| List Game Preferences | getgamepref | Every preference, or just the ones matching a filter |
| List Game Stats | getgamestat | The same for stats |
Custom
Custom Command sends whatever you type, exactly as typed. Nothing checks it first, so the syntax has to be right. help <command> in the Console tab prints the game's own usage for any of them.
Reaching every player without typing names
Ten commands take a player - Message One Player, Kick, both Teleports, Buff, Remove Buff, Give Item, Give XP, Spawn Screamers Near a Player, and Spawn Entity Near a Player. Each shows an Send to every online player checkbox beside the player field.
Tick it and you type no names at all. When the schedule fires we read the roster off the server and send the command once per person, one row per player in the history.
7 Days to Die has no "everyone" selector of its own, so this really is one command per player. Ten people online is ten
buffplayerlines. That is normal.
Why it uses entity IDs
The identifier substituted is the player's entity ID - the number listplayers prints beside each name - not their name.
The console splits a command on spaces:
buffplayer Bob Smith buffFooThat is read as buffing a player called "Bob" with a buff called "Smith". A name with a space in it silently targets the wrong thing. An entity ID is digits, so it cannot be misread.
buffplayer 172 buffFooThe same trap applies when you target one player by hand. If their name has a space, use their entity ID from
listplayers.
What happens in each case
| Situation | Result |
|---|---|
| Nobody online | Nothing sent. A no-op, not a failure |
| The roster cannot be read | The step is an error and nothing is sent |
| Someone joins a second before it fires | They are included - the roster is read at execution time |
That second row is deliberate. An empty server and one whose telnet refused the connection look identical from a distance, and treating the second as the first is how a giveaway reports success having given nothing to anybody.
Four things that behave differently on a schedule
| What | Why |
|---|---|
| A horde has nobody to hunt | A wandering horde normally heads for whoever called it. A schedule is not a player, so it wanders instead. It is still a real horde - do not put one on a blood-moon night |
| Screamers need a target, and will say so | spawnscouts on its own is refused from a schedule: the game answers "can only be used by a player". Use Spawn Screamers Near a Player, or at Coordinates if nobody has to be online |
| Set Game Time is riskier than it looks | Moving the clock affects timers written into the save. Use it deliberately, never hourly |
| Shutdown does not restart | Nothing brings a stopped 7 Days to Die server back on its own. It stays down until you press Start, or the panel's Auto-Restart setting starts it |
For a horde that hunts one player, run it from the in-game console instead. For a nightly restart, use Automatic Daily Restart rather than scheduling a shutdown.
Schedules worth building
| Want | Build |
|---|---|
| Insurance against a crash | Save World, Hourly at minute 0 |
| A blood-moon warning | Broadcast Message on your horde days, plus Show Next Horde Time hourly |
| A reason to log on at a set time | Spawn Airdrop, daily at 20:00 |
| A record of when your server is busy | List Online Players, */30 * * * * |
| A Friday buff for everyone | Buff Player, Send to every online player ticked, weekly |
| A weekly giveaway | Give Item to Player, Send to every online player ticked, an exact item name from listitems |
| A map that fills itself in | Render Map Area over the part of the world your players use, once, off-peak |
| A leak you can see coming | Memory Info every 6 hours |
A restart nobody can complain about
Switch the schedule to Multi-Step:
| Step | Wait | Command |
|---|---|---|
| 1 | — | Broadcast "Restart in 30 minutes" |
| 2 | 20 min | Broadcast "Restart in 10 minutes" |
| 3 | 9 min | Broadcast "Restart in 1 minute" |
| 4 | 1 min | Save World |
| 5 | — | Shutdown |
One trigger, five steps, and the warnings cannot drift away from the restart they are warning about. Set Run this to "Only while the server is up" so it does not fire at a server that is already down.
Reading the history
Click Log for the last 50 executions, each with the exact command sent, the server's reply, and a status.
| Status | Means |
|---|---|
| Success | Sent, and the server replied. Its reply is stored underneath |
| Error | Something went wrong. Most often telnet refusing the connection because the server is stopped |
| Skipped | A run condition turned this occurrence away. Not a failure |
| Missed its run | Has not fired for longer than you allowed. The card turns orange |
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.
Each status and what to check: Command Manager Troubleshooting.
Everything else a schedule can do
Multi-step sequences, waits, run conditions, overlap policy, catch-up windows, start spread and missed-run alerts work the same on every game.
| For | See |
|---|---|
| The full walkthrough | Command Manager Guide |
{players} and friends | Command Manager Variables |
| Driving it from Discord | Scheduling Commands from Discord |
| Driving it from your code | Command Manager API |
| What these commands do in-game | 7 Days to Die Admin Commands |