Scheduled Restarts and Player Notices for a Valheim Server

A scheduled restart is a maintenance window, not a cure for every Valheim server problem. Iron Gate documents a 30-minute default save interval and tells operators to stop the dedicated server with CTRL+C; those are separate controls. Set a restart only when you can explain why it is needed, let the process stop cleanly, and check the expected world after it comes back.

If you prefer a browser panel to maintaining a host service and timer, Game Hosting’s Valheim plans document an integrated panel with settings and scheduled restarts. A self-managed Linux server can use systemd without another provider, but you own the service, logs, messages and recovery checks. Our comparison of Valheim server manager GUIs explains the tradeoffs between local tools and a hosted panel. Neither approach makes a restart a substitute for a tested backup.

Decide whether a restart is due#

Do not copy a daily schedule from another server without a reason. Iron Gate’s dedicated-server guide lists -saveinterval 1800 as the default save interval. That is 1,800 seconds between saves, not a recommendation to restart every 30 minutes or every day. A restart interrupts players and does not demonstrate that a world file is healthy.

Choose a cadence from an event your group can name:

• A game update: schedule a window when the server build needs an update and players have time to leave. See the safe update checklist before changing server files.
• A repeatable fault: record what happens, when it starts, and whether a restart actually clears it. If it returns, investigate logs and resource use instead of shortening the interval.
• An operator policy: a community may reserve a regular window for maintenance. Make the interval a convenience with a named owner, not an unsupported stability guarantee.

If the server is stable and nobody needs a maintenance window, there is no requirement in the reviewed manual to restart it on a daily timer. Keep crash recovery and planned restarts separate: a service manager may bring a crashed process back, while a maintenance timer deliberately interrupts a running session.

Pick a window players can plan around#

Choose a local time and write down its time zone. Check your group’s usual play hours, expected session length and any update that will change the server build. Avoid overlapping an automatic update task, another restart timer or a backup job unless the order is documented and tested.

For a small group, one planned window can be easier to coordinate than several speculative restarts. If you run more than one task, decide which runs first: notify players, stop the server, make any intended copy, update if required, start the process, and verify the world. A provider panel may offer a “wait until empty” option, but that behavior depends on the specific host and setting; confirm what happens when a player stays connected.

Do not combine a restart with an untested update just because both happen during maintenance. Keep the server files and world recovery path identifiable. Iron Gate notes that its server launch scripts can be reset by updates, so maintain a copy of any customized startup script as its manual recommends.

Schedule a graceful Linux stop with systemd#

On a Linux host where you administer the Valheim process, run it as a managed service and schedule the restart through one scheduler. Iron Gate’s procedure is to stop the server with CTRL+C; closing the terminal window can leave the process running. A service unit should therefore send the signal that corresponds to that stop behavior and give the process time to exit. Do not assume Docker’s default stop signal is the same.

Before enabling a timer, inspect the service that actually owns the server:

systemctl --user status valheim.service
systemctl --user cat valheim.service

Use a service stop signal and timeout that match your installation, and test them against a disposable world. If your unit runs Valheim directly, a systemd service can be configured along these lines (replace the executable and arguments with your real paths):

[Unit]
Description=Valheim dedicated server
After=network-online.target

[Service]
Type=simple
WorkingDirectory=%h/valheim
ExecStart=%h/valheim/valheim_server.x86_64 -name "My Valheim server" -world "Dedicated" -password "replace-this" -savedir %h/.config/unity3d/IronGate/Valheim
KillSignal=SIGINT
TimeoutStopSec=120
Restart=on-failure

[Install]
WantedBy=default.target

The example is a service shape, not a drop-in configuration for every distribution or installation. Keep credentials out of shared scripts; use a protected environment file or your existing secret method. Confirm the real save directory and launch arguments before moving an existing world. If another panel, container manager or service already owns the process, do not start a second copy.

Create a separate one-shot unit that asks systemd to restart the named service, then a timer for the calendar window. For a user service, the action can be systemctl --user restart valheim.service; for a system service, use the system manager and its service name. A calendar timer follows the host’s configured time zone unless you specify one in the unit. Enable and inspect it with:

systemctl --user daemon-reload
systemctl --user enable --now valheim-restart.timer
systemctl --user list-timers valheim-restart.timer
systemctl --user status valheim-restart.timer

Use the current systemd timer documentation for OnCalendar= syntax and missed-run behavior. For example, OnCalendar=Sun *-*-* 05:00:00 is a weekly calendar pattern, not a recommendation that Sunday at 05:00 is right for your players. Check the host time zone and next trigger in list-timers. If you set Persistent=true, a missed calendar event can be acted on when the timer becomes active again; decide whether a catch-up restart is acceptable after downtime.

The restart action can be a separate one-shot service:

[Unit]
Description=Restart Valheim for the maintenance window

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl --user restart valheim.service

Point a timer at that service. Change the calendar expression to the window you announced:

[Unit]
Description=Weekly Valheim maintenance restart

[Timer]
OnCalendar=Sun *-*-* 05:00:00
Persistent=false
Unit=valheim-restart.service

[Install]
WantedBy=timers.target

Save these as valheim-restart.service and valheim-restart.timer in the same user-unit directory as valheim.service. For system-wide units, remove --user from the action and use the system unit directory. A user service manager must remain available while the timer is due; for an unattended host, use a system service or confirm that the user manager is configured to stay active. Keep one scheduler responsible for the restart.

Do not make the restart action start an unbounded chain of timers. Keep the timer’s target explicit, verify there is only one active Valheim process, and test both a normal stop and the timer-triggered restart on a disposable world before relying on it for a live campaign. If the service cannot stop within its timeout, investigate the process and logs; do not shorten the timeout until the server is killed abruptly.

I tested the process path on October 15, 2026, with a disposable Linux server installation: a persistent systemd user service and a one-shot timer restarted the process successfully, and a later SIGINT stop exited with status 0 and logged world reload and shutdown messages. The smoke world had no player progress, and I had no compatible game client here, so that test does not prove a populated world’s save integrity or an external player connection. Treat the player and world checks above as required before announcing a live restart as complete.

Use a provider panel without stacking schedules#

For a managed server, use the host’s documented scheduler and confirm the controls that apply to your plan. Game Hosting’s Valheim service documents scheduled restarts alongside the game settings panel. A panel can remove the need to maintain a separate Linux service, but you should still check the selected time zone, repeat interval, behavior with connected players and what happens if the task fails.

Before saving a panel task, compare it with existing schedules. A restart at 04:00 and a backup at 04:00 may race unless the provider defines their order. If you also configured a host-level timer, choose one owner and disable the duplicate. After creating a task, note its next run in the panel and confirm the task status after the first window.

Tell players when maintenance will happen#

Do not promise an automatic vanilla countdown unless you have verified that exact server build and delivery channel. A manual notice is simple and honest. Post where your group already coordinates, and include the time zone, expected interruption, reason and a place to report a problem:

Valheim maintenance: restarting the server at 05:00 UTC on Sunday for the scheduled update. Please leave the world before then. I expect a short interruption and will post again after I check the server and world.

If you do not know how long the update will take, say that the end time is unknown. After the server is checked, post that it is back and name any build mismatch or continuing issue. Do not tell players that a world is safe just because a process started.

A mod may add scheduled announcements, but it is a different operating choice from a vanilla server. For example, the current ServerManager maintainer page documents scheduled announcements with requirements including a compatible server and clients, BepInEx/plugin installation, and crossplay disabled. Those constraints can make it unsuitable for a group. Follow the maintainer’s current version instructions and test messages with a separate world and every player platform before relying on it.

Verify the same world after startup#

Check more than the “active” badge. After the scheduled window:

1. Confirm the service or panel reports one running server process and the expected server build.
2. Read the startup log for the intended world name and any errors. Compare it with the name and save path you recorded before maintenance.
3. Have an authorized player connect with a compatible client. Confirm a familiar landmark or recent group progress is present.
4. If you use crossplay, verify that the client and server builds are compatible. Iron Gate’s October 15, 2026 patch notes report that Mac App Store crossplay with other platforms will not work until that store build catches up. A restart cannot resolve a version mismatch.
5. Check the player’s report and the server log before announcing the world as ready.

Do not test by overwriting the live world. If the wrong world loads or the process fails, stop before making more changes and preserve the existing world directory and logs. Then follow your backup procedure on a copy. A successful restart does not prove that a backup can be restored.

Record missed runs and recurring failures#

Keep a short maintenance log with the planned time and time zone, reason, operator, server build, stop/start result, world name checked and player confirmation. Record skipped runs too. On a systemd host, inspect the timer’s last and next activation and the one-shot restart service’s result. In a provider panel, save the task status or error it displays.

If a job failed, do not immediately add another scheduler or reduce the interval. Check whether the host was online, the task targeted the right service, an update changed the launch script, the stop exceeded its timeout, or another tool already owned the process. Correct one cause, rerun the task on a safe world, and update the notice process if the expected downtime changes.

The useful schedule is the one your group can understand and the operator can verify. Keep automatic crash recovery, saves, backups and planned maintenance as distinct jobs, then confirm the same world and compatible clients before saying the restart is complete.