Rust Server Restart Schedule: Why and How

Most Rust admins restart their servers once a day. A planned restart at a quiet hour is cheap, while an out of memory kill or a freeze at peak time costs players their progress. The usual setup is a daily restart announced in chat, with a world save right before the stop. This guide covers why that works, how to do it by hand, how the in-game restart command behaves under systemd, and a complete systemd timer you can copy.

Everything here was checked on our Ubuntu 26.04 test host running Rust build 25582902 under systemd 259.

Why restart a Rust server every day

Three things build up while a Rust server runs:

• Memory. The server process grows as players explore, build and loot. On a host with several servers or little headroom, that growth ends in an out of memory kill, which is a crash with no save.
• Entities. Every wall, box, deployable, dropped item and sleeper is an entity the server has to track, network and save. The count shows up in the server log on every save as Saved N ents. A restart does not delete bases, but it gives the process a fresh start with the saved world instead of hours of accumulated runtime state.
• Changes waiting to load. Config values that only apply at startup and plugins you updated during the day take effect at a predictable time instead of whenever the server next crashes.

We will not give you a magic number for how fast a server degrades, because it depends on player count, map size, plugins and host. Measure your own instead. Check memory right after a restart and again the next day:

ps -o pid,etime,rss,cmd -C RustDedicated

RSS is in KiB and ELAPSED is the uptime. On our test host, 41 minutes after a restart with nobody online, RustDedicated sat at 6,394,332 KiB, about 6.1 GiB. Then follow the entity count in the journal:

journalctl -u rust-server --since "-1d" -o cat | grep "Saved .* ents"

If memory keeps climbing day over day, or the host gets close to its limit before your restart, restart more often or move a server to another host. The out of memory guide shows how to confirm an OOM kill in the logs.

What a graceful restart looks like

A good restart has four steps, in this order:

1. Warn players in chat, several times, so they can get home and close their doors.
2. Save the world with server.save over RCON and wait for it to finish.
3. Stop the process.
4. Start it again and wait until it reports Server startup complete.

The save matters most. Rust autosaves every server.saveinterval seconds, 600 by default, so anything built or looted since the last autosave only exists in memory. On our test host, with a save sent over RCON right before the stop, the log showed Saved 69,248 ents and Saving complete one second after systemd began stopping the unit, and the unit was down 7 seconds after the stop began. Do not count on the stop itself to save. A server that does not exit within TimeoutStopSec (90 seconds by default) gets SIGKILL, and a SIGKILL skips any save. An explicit server.save before the stop costs nothing.

Downtime on a normal restart is short because the map already exists. Our test server took 1 minute 41 seconds from Started to Server startup complete on its existing 4000 size map. The first boot after a wipe is different: generating a new map took about 6 minutes 40 seconds on the same box, and the whole first start about 8 minutes. That is one more reason to keep restarts and wipes as separate events.

The in-game restart command

Rust has a console command for exactly this, restart (full name global.restart). Run it in the server console or over RCON:

restart 600 "Daily restart"

The first argument is the countdown in seconds, 300 if you leave it out. The second is an optional message shown to players. During the countdown players see Restarting in N seconds in chat. At the end the server saves and exits. To cancel, run restart -1; players see Server Restart interrupted!.

Two things to know before you rely on it:

• It does not start the server again. The process quits and something outside the game has to bring it back. With Restart=always in the systemd unit, systemd starts it 5 seconds later (RestartSec=5). With Restart=on-failure, a finished countdown is a clean exit and the server stays down. The systemd service guide explains the difference.
• It counts as an automatic restart. systemd keeps a counter of the restarts it performs on its own, NRestarts, and a manual systemctl restart resets it. Because the in-game command exits and systemd restarts the process, every finished countdown adds one. Many admins watch NRestarts as a cheap crash counter; with daily in-game restarts it grows even when nothing crashed. Check the journal for the reason: a clean exit reads Deactivated successfully with no Failed with result line.

systemctl show rust-server -p NRestarts

A systemd timer for daily restarts

If you manage the server yourself, a systemd timer plus a small script gives you warnings, a save and a clean systemctl restart, so NRestarts stays a pure crash counter. The script uses rcon-cli, which speaks Rust's WebSocket RCON with -t web. Adjust the port to your rcon.port.

/usr/local/bin/rust-restart.sh:

#!/usr/bin/env bash
set -u
RCON=(rcon -a 127.0.0.1:28016 -p "$RCON_PASSWORD" -t web)
say() { "${RCON[@]}" "say $1" || true; }

say "Server restarting in 10 minutes"; sleep 300
say "Server restarting in 5 minutes";  sleep 240
say "Server restarting in 1 minute";   sleep 50
say "Server restarting in 10 seconds"; sleep 10
"${RCON[@]}" "server.save" || true
sleep 5
systemctl restart rust-server.service

Every RCON call ends in || true on purpose: if the server is frozen and RCON does not answer, the restart still happens.

/etc/systemd/system/rust-restart.service:

[Unit]
Description=Daily Rust server restart with warnings

[Service]
Type=oneshot
EnvironmentFile=/etc/rust-server/rcon.env
ExecStart=/usr/local/bin/rust-restart.sh

/etc/systemd/system/rust-restart.timer:

[Unit]
Description=Daily Rust server restart

[Timer]
OnCalendar=*-*-* 05:50:00 Europe/London
Persistent=false

[Install]
WantedBy=timers.target

Put RCON_PASSWORD=... in /etc/rust-server/rcon.env with chmod 600. A few details:

• The timer fires at 05:50 so the restart lands at 06:00, after the 10 minute countdown.
• The service stays in the starting state until the script ends. Type=oneshot has no start timeout by default, so the 10 minute countdown is not cut off.
• Persistent=false means a restart missed while the host was off is skipped, instead of running as soon as the host boots.
• The time zone after the time keeps the restart at 06:00 local time through daylight saving changes. Leave it out to use the host's time zone.

Check the schedule before you enable it:

systemd-analyze calendar --iterations=2 "*-*-* 05:50:00 Europe/London"
systemctl daemon-reload
systemctl enable --now rust-restart.timer
systemctl list-timers rust-restart.timer

On our UTC test host, systemd-analyze printed the next run as 04:50 UTC, which is 05:50 in London during summer time. For weekdays only, use Mon..Fri *-*-* 05:50:00 Europe/London.

Choosing a restart time

• Pick the emptiest hour. Look at your player count over a normal week and choose the lowest point, often early morning for your main audience. Restart after peak, not before it.
• Stay away from wipe times. Do not schedule a restart in the hour before a wipe, and leave room around forced wipe day, the first Thursday of the month at 19:00 London time, when you will be stopping and updating the server anyway.
• Stagger servers on one host. If a host runs several servers, give each its own time so they do not all load at once and compete for CPU and disk.
• Warn long enough. Five minutes is enough for most players to get home. Ten gives people in a fight time to finish. More than that and the warnings turn into noise.
• Announce it once. Put the restart time in your server description or Discord so players plan around it.

When a normal restart does not work

A graceful restart needs a server that answers RCON. When the server is frozen, the warnings and the save fail, and if the process also ignores SIGTERM, systemctl restart waits for the stop timeout (90 seconds by default) before systemd sends SIGKILL. If you know the server is hung, skip the wait:

systemctl kill -s KILL rust-server.service
systemctl start rust-server.service

This loses everything since the last autosave, so only use it when the server is already unplayable. A daily restart also does not fix a server that crashes on its own. If NRestarts climbs without planned restarts, read the exit reason in the journal first.

Restart schedules in Panelra

Panelra does all of this from the dashboard. Open a server's restart settings, pick the hour and minute in your own time zone and choose every day, weekdays, weekends or custom days. The panel converts that time to UTC when you save the schedule, so after a daylight saving change it runs an hour earlier or later on your clock; edit and save it again to move it back. You can add several schedules to one server, name them and switch one off without deleting it.

Each schedule has a warning time of 1, 3, 5, 10 or 15 minutes. When a scheduled restart comes up, the agent on your host runs a countdown in chat. With a 5 minute warning players see Server restarting in 5 minutes, then the same message at 3 minutes, 2 minutes, 1 minute, 30 seconds, 10 seconds and each of the last 5, 3, 2 and 1 seconds. At the end it announces Server restarting now. Saving world..., runs a save over RCON, waits for it and then restarts the unit with systemctl restart, so NRestarts stays clean. The panel follows the server through starting until it answers RCON queries again. Crash and hang detection stay on during the countdown.

• Cancel a pending restart while the countdown runs; players see Restart cancelled.
• Force restart a frozen server: Panelra kills and starts it at once, with no warnings and no save, and does not report that kill as a crash.
• Safe skips. A schedule that comes due while the server is stopped is skipped and logged. A restart is refused while a wipe or game update is running on that server.
• History and Discord. Every scheduled restart shows up in the server's automation history with its trigger and result, including skipped ones, and a Discord webhook can post when a restart starts and when it finishes.

See restart scheduling, plus crash alerts and server monitoring for what happens between restarts.

Free during the open beta. Pricing will be announced before the beta ends.