Server Auto Restart Setup

Intermediate40-60 minutesWindowsUnturned ServerNotepad++

Restarting an Unturned™ dedicated server manually every time it needs maintenance is unsustainable at production scale. A server that runs unattended for days accumulates floating-point drift in its internal time tracking, its memory footprint grows with each map cycle, and its players experience gradual performance degradation that a clean restart prevents every time. The auto-restart system built into the Unturned™ dedicated server tool addresses all of these problems through configuration-file settings that control scheduled shutdowns, update-detected shutdowns, and player notification timing.

This article is the 57 Studios™ reference for the server auto-restart system. It covers every Config.json key that controls restart behavior, the recommended 24-hour restart cadence that the official documentation prescribes, the update-monitoring system that triggers shutdowns when Workshop content changes, the interaction between scheduled and update-triggered restarts, and a complete pair of worked scripts (Windows batch and Linux bash) that wrap the server executable in an infinite update-and-restart loop. Server operators who configure auto-restart correctly eliminate the most common source of silently-degrading server performance and ensure that players always run on the most recent version of the server's content.

The auto-restart system is one of the few server features that requires no plugins, no custom compiled code, and no external dependencies. Every setting lives in Config.json, and every setting takes effect on the next server restart. This simplicity makes the auto-restart system accessible to server operators of all experience levels, but it also means that its correct operation depends entirely on the operator putting the right values in the right keys. A misspelled key or a missing comma silences the entire system with no error message. This article exists to prevent that outcome.

Documentation source: The auto-restart settings documented in this article are drawn from the official Smartly Dressed Games modding documentation. The practical-application scripts are community-validated patterns that 57 Studios has tested across its server fleet.

Who this article is for

This article is written for Unturned™ dedicated server operators who have a running server and are familiar with Config.json file location and syntax. If you have not yet installed a dedicated server, start with Setting Up Your Server Panel and return here after your server is online and accessible to players. The wrapper scripting section assumes basic familiarity with the Windows command prompt or the Linux bash terminal.

What you will learn

• How to configure scheduled shutdowns that occur at the same time every day
• How to set up player warning broadcasts before a scheduled restart with multiple intervals
• How to enable update-monitoring so the server shuts down when Workshop content changes
• How to configure update-monitoring for the public branch and the preview branch independently
• How to script an infinite update-and-restart loop using Windows batch or Linux bash
• How to combine scheduled shutdowns with update-triggered shutdowns without conflict
• How to test the auto-restart system before deploying to a production server
• How to integrate backup scripts into the auto-restart loop

Background: the floating-point time problem

The Unturned™ dedicated server uses single-precision floating-point arithmetic for its internal time tracking. Single-precision floats use 32 bits to represent a numeric value, which means they have approximately seven decimal digits of precision. For a value that represents elapsed seconds since the server started, the precision loss becomes measurable after approximately 24 hours of continuous runtime. The server's tick timing drifts, scheduled events fire at slightly wrong intervals, and the synchronization between the server and its connected clients accumulates a gradually widening delta that manifests as rubber-banding, delayed hit registration, and desynchronized zombie and animal positions.

The official SDG documentation explicitly recommends restarting the server every 24 hours to reset this drift. The recommendation is not optional for production servers that serve more than a handful of players. A server that runs for a week without restarting will show progressively worse gameplay symptoms that players will attribute to "the server being laggy" even though the network latency is normal -- the desynchronization is in the game state, not the network transport.

Beyond the floating-point drift concern, a periodic restart provides several secondary benefits. Memory that the server allocated during map load but never freed (a common pattern in long-running game servers that load and unload assets) is reclaimed when the process exits. The Steam client re-authenticates its connection to the Steam backend, which resolves a class of connectivity issues that accumulate over days. Workshop content that the server's update-monitor detected as changed is applied on restart. And players who have been connected continuously for many hours benefit from the refreshed server state: desynchronization bugs that accumulated during the session are cleared, and the new map cycle restarts world resources and zombie spawns.

The auto-restart system is configured entirely through Config.json keys. No plugins are required, no custom scripts are necessary for the basic 24-hour restart, and the system works identically across Windows and Linux dedicated server deployments. The only difference between the two platforms is the wrapper script that re-launches the server after a shutdown -- the Config.json settings themselves are platform-agnostic.

The flowchart above shows the complete lifecycle of a server with auto-restart configured. The initial check for Enable_Scheduled_Shutdown determines whether the server enters the cycle at all. Once in the cycle, the server monitors the system clock continuously and fires the shutdown sequence when the configured time arrives.

Config.json auto-restart settings

All auto-restart configuration lives in the server's Config.json file. The file is located at Servers/<ServerName>/Server/Config.json relative to the Unturned™ dedicated server installation directory. Three keys control the scheduled shutdown system, and three additional keys control the update-triggered shutdown system.

The Config.json file uses standard JSON syntax. Every key and string value must be enclosed in double quotes. Boolean values (true, false) are not quoted. Trailing commas after the last entry in an object or array are not valid JSON and cause the server to silently ignore the entire file or use default values for unparseable keys.

Scheduled shutdown keys

Key	Type	Example	Required	Purpose
Enable_Scheduled_Shutdown	bool	true	Yes for scheduled restarts	Enables or disables the entire scheduled shutdown system. When false or omitted, the server does not automatically shut down at any time of day.
Scheduled_Shutdown_Time	string	04:30	Yes when scheduled shutdown is enabled	The local time of day at which the server shuts down. Specified in 24-hour HH:MM format. The server must be restarted to pick up any change to this value; it is not read dynamically at runtime.
Scheduled_Shutdown_Warnings	string	60:00,30:00,10:00,5:00,1:00	Yes when scheduled shutdown is enabled	Colon-separated list of warning lead times in MM:SS format. Each entry produces one chat broadcast to all connected players, warning them of the impending shutdown. The warnings fire in sequence as each lead time is reached.

The Scheduled_Shutdown_Warnings field accepts multiple time values separated by commas with no spaces between entries. The server processes warnings from the longest duration to the shortest: a configuration of 60:00,30:00,10:00,5:00,1:00 produces warnings at 60 minutes, 30 minutes, 10 minutes, 5 minutes, and 1 minute before the shutdown time. Each warning produces an untranslated server message in the chat area of all connected clients. The message format is generated by the server engine and is not configurable.

The warning intervals serve distinct purposes. The 60-minute warning gives players who are engaged in extended activities -- building a base, exploring a distant area of the map, engaged in a player-versus-player encounter -- sufficient time to complete or pause their activity. The 30-minute warning is a second notification for players who missed the first one. The 10-minute warning is the "final call" that most players treat as the serious deadline. The 5-minute and 1-minute warnings are urgency signals for players who are at a safe location and can simply wait for the restart.

The sequence diagram above shows a complete scheduled-shutdown cycle with five warning intervals. The warnings are evenly spaced across the final hour, giving players progressively urgent notifications as the shutdown approaches. The final warning at 1 minute gives players enough time to reach a safe logout location but not enough time to start a new extended activity.

Update-triggered shutdown keys

Key	Type	Example	Required	Purpose
Enable_Update_Shutdown	bool	true	Yes for update-triggered restarts	Enables or disables Workshop update monitoring. When true, the server periodically checks whether any subscribed Workshop items have published a new version on the Steam backend.
Update_Steam_Beta_Name	string	public	No	The Steam beta branch to check for updates. Defaults to public when not specified. Set to preview for servers running on the preview branch that need to test upcoming changes before they reach the public branch.
Update_Shutdown_Warnings	string	2:30,1:00,0:30	Yes when update shutdown is enabled	Colon-separated list of warning lead times in MM:SS format. When an update is detected, the server waits for the longest of these durations (the first value in the list), then broadcasts a warning. It continues broadcasting at each listed interval until the shortest interval expires, at which point the shutdown executes.

The update-monitoring system polls the Steam backend at intervals that the server engine controls internally. Server operators cannot configure the polling frequency. When a Workshop item that the server has loaded publishes a new version, the server's update monitor detects the version change and enters the shutdown-pending state. The server does not shut down immediately upon detecting the update -- it waits for the longest warning duration, then begins broadcasting warnings at the configured intervals, then shuts down. This delay gives players time to finish their current activity before the restart.

The waiting behavior is designed to prevent sudden restarts during peak play hours. If a Workshop mod author publishes a minor update at 3 PM on a Saturday, the server does not restart at 3 PM. It waits 2 minutes and 30 seconds (the longest interval), broadcasts a "shutdown for update in 2 minutes" warning, and continues the countdown. Players have just over 2 minutes to disengage from combat or reach a safe location.

For example, with Update_Shutdown_Warnings set to 2:30,1:00,0:30:

1. Server detects a Workshop item version change.
2. Server waits 2 minutes and 30 seconds.
3. Server broadcasts "shutdown in 2 minutes 30 seconds."
4. Server waits until 1 minute remains, broadcasts "shutdown in 1 minute."
5. Server waits until 30 seconds remain, broadcasts "shutdown in 30 seconds."
6. Server waits until 0 seconds remain, executes shutdown.

The update-triggered shutdown warning intervals are intentionally shorter than the scheduled shutdown intervals because update detection can happen at any time of day, and a long warning delay would keep players waiting during peak hours. The SDG documentation recommends keeping the longest interval under 5 minutes.

Scheduled and update-triggered shutdowns coexist independently

Both Enable_Scheduled_Shutdown and Enable_Update_Shutdown can be true simultaneously without conflict. The server processes both independently: the scheduled shutdown fires at the configured time of day regardless of update status, and the update-triggered shutdown fires when an update is detected regardless of the time of day. If an update is detected shortly before a scheduled shutdown, the update-triggered shutdown fires first (at the update-detected time with the shorter warning window), and the scheduled shutdown for that day is effectively skipped because the server is already down. This is the correct behavior -- the update restart provides the daily restart, and the scheduled restart is a fallback for days when no update is published.

Complete Config.json example with auto-restart

{
  "Enable_Scheduled_Shutdown": true,
  "Scheduled_Shutdown_Time": "04:30",
  "Scheduled_Shutdown_Warnings": "60:00,30:00,10:00,5:00,1:00",
  "Enable_Update_Shutdown": true,
  "Update_Steam_Beta_Name": "public",
  "Update_Shutdown_Warnings": "2:30,1:00,0:30"
}

The example above enables both scheduled and update-triggered shutdowns with the recommended warning intervals. The server shuts down at 4:30 AM local time daily (a time chosen to be in the lowest player-activity window for most server demographics), and any Workshop update detected during the day triggers a separate shutdown with shorter warning times that give players approximately 2.5 minutes of notice.

This configuration does not include a wrapper script reference -- the wrapper script is a separate concern that lives outside Config.json. The Config.json keys control only when and how the server shuts down. The wrapper script that re-launches the server after shutdown is covered in the next section.

Practical application: wrapper scripts for automated restart

The auto-restart Config.json settings handle only the shutdown part of the maintenance cycle. Once the server process exits, something external must restart it. The restart part -- updating the server software and Workshop content, then launching the server again -- requires a wrapper script that detects the server process exit and responds by running SteamCMD and re-launching the server.

The concept is straightforward: a loop script starts the server, waits for it to exit (which happens when the auto-restart shutdown or a manual shutdown occurs), runs SteamCMD to download the latest server update while the server is stopped, and returns to the start of the loop to launch the server again. The loop runs indefinitely until the operator manually interrupts it by pressing CTRL+C during the timeout window.

Both the Windows batch and Linux bash scripts use the Steam App ID 1110390 for the Unturned™ Dedicated Server. This is the Steam App ID for the dedicated server tool, which is a separate application from the base Unturned™ game (App ID 304930). The dedicated server tool is free and does not require owning the base game to operate or update.

Windows batch wrapper script

The following batch script should be placed in the same folder as steamcmd.exe, typically the SteamCMD installation directory. The script uses the %~dp0 variable to reference its own directory, which allows it to be called from any working directory without path issues.

@echo off

:loop
echo Updating...
start "" /wait "%~dp0steamcmd.exe" +login anonymous +app_update 1110390 +quit

echo Finished update! Launching server...
start "" /wait "%~dp0steamapps\common\U3DS\Unturned.exe" -batchmode -nographics +InternetServer/MyServer

echo Server has exited. Restarting after timeout...
echo:
echo Press CTRL+C and then Y during this timeout to cancel restart.
timeout 10

goto loop

The script uses several conventions that are worth understanding in detail:

Script element	Purpose	Alternative
@echo off	Suppresses command echo from being displayed in the terminal, keeping the output readable	Omit to see every command as it executes (useful for debugging)
:loop	Label for use with goto. The script returns to this label after each restart cycle	Any label name works; :loop is conventional
%~dp0	Expands to the path to the script's directory with a trailing backslash	Use an absolute path if the script is not in the SteamCMD directory
start "" /wait	Launches the specified program and waits for it to exit before continuing. The empty quotes provide a window title that is unused in this context	Without /wait, the script launches the server in the background and immediately loops back
+app_update 1110390	SteamCMD command to download or update App ID 1110390 (Unturned™ Dedicated Server)	Add -validate after +quit to verify file integrity on every update
+InternetServer/MyServer	Launch flag that tells the server to run as an internet server using the configuration directory named MyServer	Replace MyServer with the actual server configuration directory name
-batchmode -nographics	Unity launch flags that suppress the graphical interface and run in batch mode, which is required for dedicated server operation	Required for headless server operation; do not remove
timeout 10	Pauses the script for 10 seconds, during which the operator can press CTRL+C to cancel the restart	Increase to 30 for production to give more cancellation time
goto loop	Returns execution to the :loop label, starting a new update-restart cycle	The script runs indefinitely until the operator terminates it

The start "" /wait pattern is critical for correct operation. Without the /wait flag, the batch script launches the server process in the background and immediately proceeds to the next line, which would either attempt to run SteamCMD while the server is still running (causing a "file in use" error) or restart the server before the shutdown has completed (causing a port-binding conflict because the old process has not yet released the port). The /wait flag ensures that the script pauses at each start command until the launched process exits.

Linux bash wrapper script

The following bash script performs the same infinite-loop update-and-restart pattern on Linux. The script assumes a symbolic link to the U3DS installation directory exists at ~/U3DS. The SDG documentation notes that the actual SteamCMD installation path varies depending on how SteamCMD was installed and whether +force_install_dir was specified during setup. The two most common installation paths are:

• ~/.steam/steam/steamapps/common/U3DS
• ~/Steam/steamapps/common/U3DS

Creating a symbolic link from one of these paths to ~/U3DS simplifies the script and makes it portable across Linux distributions and SteamCMD installation methods. Create the link with:

ln -s ~/.steam/steam/steamapps/common/U3DS ~/U3DS

Or for the alternative path:

ln -s ~/Steam/steamapps/common/U3DS ~/U3DS

After the symbolic link exists, save the wrapper script as MyServer.sh in the home directory:

#! /usr/bin/bash
while true; do
    echo Updating...
    steamcmd +login anonymous +app_update 1110390 -validate +quit

    echo Finished update! Launching server...
    cd ~/U3DS
    source ServerHelper.sh +InternetServer/MyServer

    echo Server has exited. Restarting after timeout...
    echo Press Ctrl+C during this timeout to cancel restart.
    read -t 10
done

The bash script uses the same loop pattern as the Windows version but with Linux-native conventions:

Script element	Purpose	Alternative
#! /usr/bin/bash	Shebang line that tells the kernel which interpreter to use when the script is executed directly	Use /usr/bin/env bash for portable scripts across Linux distributions
while true	Infinite loop equivalent to the :loop / goto loop pattern in batch	while : is a common alternative that is slightly more portable
steamcmd	Called directly without start because Linux runs SteamCMD as a blocking foreground process by default	Add the full path to steamcmd if it is not in the system PATH
-validate	Verifies the integrity of downloaded files after the update	Omit to reduce update time at the cost of skipping integrity verification
source ServerHelper.sh	Sources the server's helper script, which sets environment variables and handles process management	Call Unturned.x86_64 directly with the same launch arguments if ServerHelper.sh is not available
read -t 10	Blocks for 10 seconds with a prompt, functionally equivalent to timeout 10 on Windows	Use sleep 10 for a silent wait without cancellation option

The bash script uses source ServerHelper.sh instead of calling the server executable directly. This is the recommended method on Linux because ServerHelper.sh sets environment variables that the Mono runtime requires for correct operation. Calling the executable directly without sourcing the helper script first may produce runtime errors related to library paths and assembly resolution.

Running the Linux wrapper script persistently

The Linux wrapper script needs to run in a persistent session that survives the operator logging out of the SSH or terminal session. The standard approach is to use screen, a terminal multiplexer that maintains a session independently of the user's login state.

screen -S MyServer
bash MyServer.sh

After confirming the server starts correctly and the loop is working, press Ctrl+A then D to detach from the screen session. The server continues running in the background. To re-attach to the screen session later:

screen -r MyServer

The -S MyServer flag names the screen session so that the operator can re-attach to the correct session when multiple screen sessions are running on the same machine. Without the name flag, screen assigns a default numeric ID that is harder to remember.

Alternative persistent-session tools such as tmux or nohup serve the same purpose. The 57 Studios™ recommendation is screen because it is installed by default on most Linux distributions and has the simplest usage pattern for server operators who are not full-time Linux administrators.

Testing the wrapper script before production deployment

The recommended deployment sequence for a new auto-restart setup follows a graduated testing approach. Each step confirms that a specific layer of the system works before moving to the next layer.

1. Configure the Config.json auto-restart keys with the desired timing and warnings. Verify the JSON syntax using a JSON validator or by pasting the file content into a JSON-aware text editor that highlights syntax errors.
2. Test the scheduled shutdown independently. Set Scheduled_Shutdown_Time to two minutes in the future by adjusting the server machine's system clock or by temporarily changing the shutdown time. Observe the server console output. Verify that the warnings broadcast at the correct intervals and that the server shuts down when the time is reached. After confirming the shutdown works, reset the shutdown time to the intended value and restart the server to reload the configuration.
3. Deploy the wrapper script in a test environment and verify the update-and-restart loop works end to end. This test requires a separate server installation or a test server directory that players do not access. Verify that SteamCMD runs without errors, that the server starts after the update, and that the script loops back to the update step after the server exits.
4. Monitor the server for at least one full restart cycle. If the scheduled shutdown time is 4:30 AM, verify the next morning that the server shut down and restarted correctly. Check the server console logs for any error messages during the shutdown or restart sequence.
5. Adjust warning intervals based on player feedback about insufficient notification time. Some communities prefer a 30-minute warning as the longest interval; others prefer 60 minutes. Observe whether players commonly complain about insufficient notice and adjust accordingly.
6. Deploy the wrapper script to production with the confirmed settings only after all previous steps pass.

Do not skip step 2. A Config.json syntax error -- a missing comma, a misspelled key, a string value without quotes -- causes the server to silently ignore the auto-restart settings, and the first indication of a problem is a server that runs for days without restarting. The server engine does not log a warning for invalid JSON keys; it simply uses default values (or no value) for unparseable entries.

Configuring the server name in wrapper scripts

Both the Windows and Linux reference scripts use +InternetServer/MyServer as the server launch argument. The server name after the slash must match the name of a subdirectory under the server's Servers/ directory. The +InternetServer flag tells the server to launch as an internet server using the configuration from that named directory.

For example, a server with its configuration directory at Servers/MySurvivalServer/ would use:

+InternetServer/MySurvivalServer

A server with its configuration at Servers/MyRoleplayServer/ would use:

+InternetServer/MyRoleplayServer

The server name in the launch argument is case-sensitive on Linux (because the underlying file system is case-sensitive) and case-insensitive on Windows (because NTFS is case-preserving but case-insensitive). To maintain portability between the two platforms, use the exact casing of the directory name as it appears on the file system.

If the wrapper script launches the server but the server immediately exits with no error message, the most likely cause is a mismatch between the server name in the launch argument and the directory name on the file system. Verify the directory listing under Servers/ and correct the launch argument.

Interaction between auto-restart and plugin-based restart systems

Some server plugins (RocketMod, OpenMod, custom implementations) provide their own restart scheduling. When a plugin-based restart system is active alongside the built-in auto-restart, the interaction depends on which system triggers first.

If the built-in scheduled shutdown fires first, the plugin triggers the same shutdown (or detects that a shutdown is already in progress) and does not attempt a second restart. On the next boot, the plugin's scheduled timer has been reset by the restart, so the plugin schedules its next restart from the new boot time.

If the plugin fires first, the built-in system's timer is moot because the server has already shut down. When the server restarts, the built-in timer resumes from the new boot time, but it has missed its window for that day. The scheduled shutdown will fire at the configured time the following day.

The 57 Studios™ recommendation is to use only one restart scheduling system. The built-in system is simpler and more reliable because it has no dependency on plugin load order, plugin compatibility with the current server version, or plugin framework updates that change the plugin's scheduling API. If you need restart features that the built-in system does not support -- such as restart-only-if-no-players-are-online, restart-at-a-specific-player-count-threshold, or restart-on-a-custom-schedule-that-varies-by-day-of-week -- consider a plugin as a supplement that checks the relevant condition and then either allows or postpones the built-in restart rather than implementing its own independent restart timer.

Diagnostic table

Symptom	Most likely cause	Resolution
Server does not shut down at scheduled time	Enable_Scheduled_Shutdown is false, the key is misspelled, or the JSON has a syntax error	Verify the key exists, is set to true, and the JSON is valid. Restart the server after making changes
Server shuts down but does not restart	No wrapper script is running around the server process	Deploy the Windows batch or Linux bash wrapper script. The Config.json settings only handle shutdown, not restart
Players report no warning before shutdown	Scheduled_Shutdown_Warnings is empty, missing, or uses an incorrect format	Verify the field exists in Config.json and contains comma-separated values in MM:SS format
Server restarts immediately after shutdown, then shuts down again	Update-triggered shutdown detected an update during the brief window between shutdown and wrapper restart	Increase the wrapper script's timeout duration to allow SteamCMD to complete before relaunching
Warnings appear but the server never actually shuts down	The Scheduled_Shutdown_Time value is after the current time in a multi-day server runtime or the time format is incorrect	Verify the time format is 24-hour HH:MM (e.g., 04:30 not 4:30 AM) and restart the server to reload Config.json
Update-triggered shutdown does not fire	Enable_Update_Shutdown is false or the Steam backend is unreachable from the server machine	Verify the key setting and confirm the server can reach api.steampowered.com on port 443
Wrapper script launches SteamCMD but SteamCMD fails to log in	SteamCMD cannot reach the Steam login servers due to firewall or DNS issues	Verify outbound HTTPS connectivity on port 443 and DNS resolution for Steam domains
Server launches but immediately exits with no error message	The server name in the wrapper script does not match any directory under Servers/	Confirm the directory listing under the U3DS Servers/ folder and correct the name in the launch argument
Server runs for multiple days without restarting despite scheduled shutdown being enabled	The server process was launched directly through its executable, not through the wrapper script	Kill the server process and relaunch using the wrapper script
Warnings broadcast at unexpected times	The server machine's time zone does not match the operator's expectation	Verify the system time zone setting (Windows: tzutil /g, Linux: timedatectl) and adjust the shutdown time accordingly
Scheduled shutdown warning broadcasts a default message that cannot be customized	The server engine does not support custom warning message text	Use a plugin to suppress the built-in message and broadcast a custom message
Multiple servers on the same machine restart at the same time	The scheduled shutdown times are not staggered	Set each server's Scheduled_Shutdown_Time at least 15 minutes apart from the others
Server exits but wrapper script fails to detect the exit and restart	The wrapper script does not use /wait (Windows) or blocking process execution (Linux)	Add the /wait flag to the start command in batch, or use source with the server helper script on Linux
Backup script in the wrapper loop runs but produces empty or missing backups	The backup path does not exist or the backup command runs before the server state is fully written to disk	Verify the backup destination directory exists and add a brief ping or sleep delay between the server exit and the backup step

Worked example: configuring auto-restart for a production survival server

This worked example walks through the complete auto-restart configuration for a hypothetical production survival server named "SurvivalCraft." The server is a standard Unturned survival experience with a curated Workshop modlist, running on a Linux VPS with 8 GB of RAM. The server averages 15-25 concurrent players, with peak hours between 6 PM and 11 PM local time, and the lowest activity window between 3 AM and 6 AM local time.

Step 1: analyze player activity metrics

Before choosing a shutdown time, the server operator examines the server's player activity logs for the preceding two weeks. The logs show that the average player count drops below 3 players after 4 AM local time and stays low until approximately 8 AM. The operator chooses 5:00 AM as the shutdown time -- late enough that the small number of early-morning players have warning, and early enough that the server is back online before the morning activity uptick begins.

Step 2: configure Config.json keys

The operator edits Config.json located at Servers/SurvivalCraft/Server/Config.json. The relevant section of the file after editing:

{
  "Enable_Scheduled_Shutdown": true,
  "Scheduled_Shutdown_Time": "05:00",
  "Scheduled_Shutdown_Warnings": "60:00,30:00,15:00,5:00,1:00",
  "Enable_Update_Shutdown": true,
  "Update_Steam_Beta_Name": "public",
  "Update_Shutdown_Warnings": "3:00,1:00,0:30"
}

The operator chooses five warning intervals for the scheduled shutdown (60, 30, 15, 5, and 1 minute) and three intervals for the update-triggered shutdown (3, 1, and 0.5 minutes). The update beta name is left at public because the server is a production environment that should not run preview builds.

Step 3: validate the JSON syntax

The operator pastes the file content into a JSON validator to confirm there are no syntax errors. The validator reports valid JSON. This step catches two common mistakes before they affect the server: a missing comma after the Scheduled_Shutdown_Time line (which would merge the string values into an invalid construct) and an unquoted value in one of the warning strings (which would produce a parse error).

Step 4: test the scheduled shutdown

The operator temporarily sets Scheduled_Shutdown_Time to the current time plus 2 minutes (if the current time is 14:30, the operator sets it to 14:32) and restarts the server. The server broadcasts warnings at the configured intervals and shuts down at 14:32 as expected. The operator then resets the shutdown time to 05:00 and restarts the server again to load the corrected value.

Step 5: write and deploy the wrapper script

The operator creates SurvivalCraft.sh in the home directory with the following content:

#! /usr/bin/bash
while true; do
    echo Updating...
    steamcmd +login anonymous +app_update 1110390 -validate +quit

    echo Finished update! Creating backup...
    mkdir -p /backups/survivalcraft
    tar -czf /backups/survivalcraft/server-$(date +%Y%m%d-%H%M).tar.gz ~/U3DS/Servers/SurvivalCraft

    echo Finished backup! Launching server...
    cd ~/U3DS
    source ServerHelper.sh +InternetServer/SurvivalCraft

    echo Server has exited. Restarting after timeout...
    echo Press Ctrl+C during this timeout to cancel restart.
    read -t 15
done

The operator adds a backup step between the update and the launch commands, using a 15-second timeout to give the backup time to complete.

Step 6: create a symbolic link for the U3DS directory

The operator's SteamCMD installation is at the default path. The operator creates the symbolic link:

ln -s ~/.steam/steam/steamapps/common/U3DS ~/U3DS

Step 7: launch the wrapper script in a screen session

The operator opens a screen session and starts the script:

screen -S SurvivalCraft
bash SurvivalCraft.sh

The server launches, and the operator confirms the startup log shows no errors. The operator detaches from the screen session with Ctrl+A, D.

Step 8: monitor the first restart cycle

The operator checks the server the following morning shortly after 5 AM. The server is online and the restart log shows the shutdown fired at 5:00 AM, the backup completed, SteamCMD updated the server, and the server relaunched. The entire cycle took approximately 4 minutes (from 5:00 AM shutdown to 5:04 AM server ready for connections).

Step 9: communicate the schedule to players

The operator posts an announcement in the server's Discord channel:

Auto-restart is now active. Our server restarts daily at 5:00 AM local time. Warnings are broadcast at 60, 30, 15, 5, and 1 minute before restart. Workshop updates may trigger an additional restart with shorter warning times. Estimated downtime per restart is 3-5 minutes.

This communication sets clear expectations and reduces player confusion when the first restart fires.

The worked example above shows the complete end-to-end setup for a typical production server. The 9-step process takes approximately 30 minutes for an operator who has their server credentials and configuration access ready. Most of the time is spent in the testing and monitoring steps, not in the configuration editing.

Frequently asked questions

What happens if the server is in the middle of a game when the shutdown warning countdown reaches zero?

The server shuts down immediately. All connected players are disconnected from the server, and any unsaved progress since the last auto-save is lost. This is the expected behavior for a maintenance restart -- the auto-restart system assumes that the warning period gives every player sufficient time to reach a safe stopping point before the shutdown executes. If players on your server consistently report losing progress due to insufficient warning, increase the earliest warning interval in Scheduled_Shutdown_Warnings to give more lead time.

Can I set different shutdown times for different days of the week?

No. The Scheduled_Shutdown_Time field accepts a single time value, and the server shuts down at that same time every day. There is no built-in mechanism for different schedules on weekdays versus weekends. If you need a variable schedule (for example, a later restart on weekends when more players are online), use a plugin-based restart system in addition to or instead of the built-in system, or write a wrapper script that reads a day-of-week-aware configuration file and sets the shutdown time dynamically.

Does the scheduled shutdown respect players who are actively in combat?

No. The server does not check player state before executing the shutdown. The shutdown fires at the configured time regardless of whether players are in combat, in a building menu, in a vehicle, or in a cutscene. The warning system is the mechanism that gives players time to disengage before the shutdown occurs. For servers where combat continuity is a high priority, the 57 Studios™ recommendation is to set the earliest warning interval to 30 minutes or more so that players have adequate notice to disengage from extended combat encounters.

Can the update-triggered shutdown be disabled while keeping the scheduled shutdown active?

Yes. The two systems are independently controlled by separate Config.json keys. Set Enable_Update_Shutdown to false and keep Enable_Scheduled_Shutdown set to true. The server restarts at the scheduled time each day but does not restart in response to Workshop content updates. This configuration is appropriate for servers that run a curated, manually updated modlist where the operator wants full control over when updates are applied.

How long does the server wait after detecting an update before starting the shutdown countdown?

The server waits for the longest duration specified in Update_Shutdown_Warnings before beginning the countdown. For example, with Update_Shutdown_Warnings set to 2:30,1:00,0:30, the server waits 2 minutes and 30 seconds after detecting the update before broadcasting the first warning. During this waiting period, the server continues running normally and no warnings are broadcast to players. This delay prevents the server from broadcasting warnings for updates that are detected but then reverted or corrected by the mod author within the waiting window.

What happens if the scheduled shutdown time occurs while the server is processing an update-triggered shutdown?

The two events are independent, but only one shutdown executes. If the scheduled shutdown time arrives while the server is already in the update-triggered shutdown countdown, the scheduled shutdown event is effectively skipped because the server is already shutting down. The next scheduled shutdown (24 hours later) fires normally after the server has restarted and accumulated another day of runtime.

Can I customize the text of the warning broadcast?

No. The warning broadcast text is generated by the server engine and cannot be modified through Config.json or any other configuration file. The message format is hardcoded and reads approximately "Server is shutting down in X minutes" in the default language. Custom warning messages require a plugin that suppresses the built-in broadcast and sends its own formatted message through the server chat API.

Is the 24-hour restart recommendation mandatory?

No, it is a recommendation, not a requirement. The SDG documentation recommends restarting every 24 hours but does not enforce this restriction in the server code. Servers can run longer without restarting, but floating-point drift and memory accumulation become measurable after 24 hours and progressively worse after every subsequent day. Some community servers run for 48 or 72 hours between restarts with acceptable results, particularly on maps with low entity counts and modest player populations. The 57 Studios™ recommendation for production servers with 10 or more concurrent players is to restart every 24 hours as the SDG documentation advises.

Does the wrapper script need to be updated when the server software updates?

No. The wrapper script calls steamcmd +app_update 1110390 which always downloads the latest published version of the Unturned™ Dedicated Server. When a new server version is released, the wrapper script downloads and applies it on the next loop iteration automatically. The script itself does not need modification for routine server updates. The only time the wrapper script might need updating is if the server launch arguments change in a future Unturned™ version or if the wrapper script path needs to be adjusted for a new server directory layout.

What is App ID 1110390?

1110390 is the Steam Application ID for the Unturned™ Dedicated Server tool. This is a separate Steam application from the base Unturned™ game, which uses App ID 304930. The dedicated server tool is free to download, install, and operate independently of the base game -- a server operator does not need to own Unturned™ on Steam to run a dedicated server. The wrapper script's app_update command references 1110390 because that is the App ID for the dedicated server software that the script manages.

Why does the wrapper script update the server before launching but not after the server exits?

The update-before-launch pattern ensures that the server always runs on the most recent published version. If the server ran for 24 hours and a new version was published during that time, the update step that runs immediately after the server exits downloads and applies the new version before the server starts again. If the update step ran after launch instead of before it, the server would start on the old version and only update after the next shutdown, which means the server would run on an outdated version for a full day.

Can I run the wrapper script as a Windows service or Linux systemd unit?

Yes, but the reference scripts are designed for interactive use and are not directly suitable as service or systemd configurations. Running the wrapper script as a Windows service requires additional tooling (such as NSSM -- the Non-Sucking Service Manager) to handle process monitoring and automatic restart after system reboots. Running as a systemd unit on Linux requires creating a .service unit file that replaces the infinite loop with systemd's restart behavior. The 57 Studios™ recommendation for new server operators is to start with the interactive reference scripts and only migrate to service management after the basic auto-restart cycle is confirmed working.

How do I stop the server permanently without the wrapper script restarting it?

To stop the server and prevent the wrapper script from restarting it, press CTRL+C during the timeout window. On Windows, press CTRL+C while the timeout 10 message is displayed, then press Y when prompted. On Linux, press CTRL+C during the read -t 10 pause. If you miss the timeout window and the server relaunches, press CTRL+C in the server process window to kill it, then immediately press CTRL+C in the wrapper script window to break the loop before it reaches the goto loop or while true statement.

Best practices

• Always set both Enable_Scheduled_Shutdown and Enable_Update_Shutdown to true for production servers. They address different restart needs -- scheduled shutdowns provide predictable daily maintenance, and update-triggered shutdowns ensure Workshop content is never stale for more than a few hours.
• Configure at least three warning intervals for scheduled shutdowns. The cohort-validated set is 60 minutes, 30 minutes, and 10 minutes. The 60-minute warning gives players time to finish extended activities such as base building or long-distance travel; the 30-minute warning catches players who dismissed the first message; the 10-minute warning is the final clear signal that players should prepare to log out.
• Test the wrapper script in a non-production environment before deploying to a live server. A script error that prevents the server from restarting is much harder to diagnose at 4 AM when the production server has already shut down and players are waiting for it to come back online.
• Use a screen session on Linux or a dedicated terminal on Windows rather than running the wrapper script as a hidden background process initially. Being able to see the console output in real time makes it easier to observe the loop behavior and debug startup issues during the first few days of operation.
• Keep the wrapper script in the same directory as SteamCMD. The %~dp0 and relative-path conventions in the reference scripts assume this directory layout, and placing the script elsewhere requires adjusting the paths.
• Document the server name that the wrapper script uses. An operator who forgets which +InternetServer/ name the script references may inadvertently create a second server configuration directory rather than fixing the script, which leads to confusion about which configuration the server is actually running.
• Set the server machine's time zone to match the time zone of the majority of your player base. The shutdown time is relative to the server machine's local time, and players who see a "shutdown in 60 minutes" message at what they perceive as 3 AM will be confused if the server operator intended the shutdown for 4 AM their time.
• Avoid setting Scheduled_Shutdown_Time during peak play hours. Study the server's player-count metrics over a period of at least one week and choose a shutdown time during the lowest-activity window. For most servers, this window falls between 3 AM and 6 AM local time.
• Keep the Update_Shutdown_Warnings intervals short (under 5 minutes total). Update-triggered shutdowns can happen at any time of day, and a long warning window during peak hours would inconvenience players significantly more than a quick 2-minute notice.
• Validate Config.json syntax after every edit. A single missing comma or unclosed quote disables the auto-restart system silently. Use a JSON validator or paste the file content into a JSON-aware editor before restarting the server.

Advanced considerations

Multiple servers on the same machine

If you run multiple Unturned™ dedicated server instances on the same physical or virtual machine, each instance has its own Config.json file and its own auto-restart configuration. The scheduled shutdown times should be staggered by at least 15 minutes so that the wrapper scripts do not attempt to update and restart simultaneously, which would cause port-binding conflicts if the server instances share the same port range or directory structure.

The wrapper scripts for multiple servers should reference different +InternetServer/ names and should each maintain their own SteamCMD update step. A common mistake is to write one wrapper script that runs SteamCMD once and then launches multiple server instances from the same updated installation. This does not work because the server instances each have their own Workshop subscription state and must each be launched with their own +InternetServer/ argument pointing to the correct configuration directory.

For a two-server setup, the wrapper scripts would look like:

Server 1 wrapper: +InternetServer/MySurvivalServer (shutdown at 04:00)
Server 2 wrapper: +InternetServer/MyRoleplayServer  (shutdown at 04:30)

Each script runs its own SteamCMD update independently. The 30-minute stagger prevents both servers from being down simultaneously if an update-triggered shutdown fires before the scheduled shutdown time.

Server maintenance window communication

The auto-restart warning system broadcasts messages to the in-game chat, which is effective for players who are currently connected but does not reach players who are offline at the time of the broadcast. For community servers with a Discord presence, the 57 Studios™ recommendation is to additionally configure a Discord bot or webhook that posts the restart schedule in a designated channel. Players who are in Discord but not in-game at the time of the scheduled shutdown will see the Discord notification and know when to expect the server to be unavailable.

The Discord notification should include:

• The scheduled shutdown time (in the server's local time zone)
• The number of warning intervals and their durations
• The estimated downtime (usually 2-5 minutes for a standard restart)
• A link to the server's status page or a way to check when the server is back online

Combining auto-restart with server backup scripts

The wrapper script's post-shutdown pause is an ideal opportunity to create a server backup. The server state is consistent because the server has shut down cleanly, and the backup runs before SteamCMD modifies any files. Place the backup command between the server exit and the SteamCMD update step.

For Linux, a tar-based backup within the wrapper script:

echo Server has exited. Creating backup...
tar -czf /backups/myserver-$(date +%Y%m%d-%H%M).tar.gz ~/U3DS/Servers/MyServer

For Windows, a PowerShell-based backup within the wrapper script:

echo Server has exited. Creating backup...
powershell -Command "Compress-Archive -Path '%~dp0steamapps\common\U3DS\Servers\MyServer' -DestinationPath 'C:\backups\MyServer-%DATE:~10,4%%DATE:~4,2%%DATE:~7,2%.zip'"

Both commands create a timestamped archive file in the specified backup directory. The backup runs during the timeout window and completes before the update step begins. If the backup takes longer than the timeout duration, increase the timeout value to accommodate the backup time.

Floating-point drift mitigation beyond restart

The 24-hour restart cadence is the only mitigation for single-precision floating-point drift that the built-in server system provides. There is no Config.json key to increase the precision of the time tracking or to reduce the drift rate. The drift is a fundamental limitation of the 32-bit floating-point format that the server uses for its internal clock. The only remediation is the restart, which resets the clock to zero.

Server operators who want to extend the interval between restarts beyond 24 hours should measure the drift on their specific server hardware and map combination. Some servers show acceptable precision for 48 or even 72 hours, while others show unacceptable drift after 18 hours. The drift rate depends on the server's tick rate, the number of connected players, and the complexity of the map. Measure empirically, do not assume.

Appendix A: Config.json auto-restart quick reference

Key	Type	Required	Default	Purpose
Enable_Scheduled_Shutdown	bool	No	Not set (disabled)	Enables or disables daily scheduled shutdown
Scheduled_Shutdown_Time	string	Conditional	None	Local time (24-hour HH:MM format) for daily shutdown
Scheduled_Shutdown_Warnings	string	Conditional	None	Comma-separated MM:SS warning lead times
Enable_Update_Shutdown	bool	No	Not set (disabled)	Enables or disables update-triggered shutdown
Update_Steam_Beta_Name	string	No	public	Steam beta branch to monitor for updates
Update_Shutdown_Warnings	string	Conditional	None	Comma-separated MM:SS warning lead times for update-triggered shutdown

Appendix B: Wrapper script command quick reference

Platform	Action	Command
Windows batch	Update server	start "" /wait "%~dp0steamcmd.exe" +login anonymous +app_update 1110390 +quit
Windows batch	Launch server	start "" /wait "%~dp0steamapps\common\U3DS\Unturned.exe" -batchmode -nographics +InternetServer/MyServer
Windows batch	Pause for cancellation	timeout 10
Linux bash	Update server	steamcmd +login anonymous +app_update 1110390 -validate +quit
Linux bash	Launch server	cd ~/U3DS && source ServerHelper.sh +InternetServer/MyServer
Linux bash	Pause for cancellation	read -t 10
Linux screen	Create persistent session	screen -S MyServer
Linux screen	Detach from session	Ctrl+A, D
Linux screen	Re-attach to session	screen -r MyServer

Appendix C: System time zone verification commands

Platform	Command	Output example
Windows	tzutil /g	Eastern Standard Time
Linux	timedatectl	Time zone: America/New_York (EST, -0500)
Linux	date +%Z	EST

Appendix D: External references

• Smartly Dressed Games modding documentation -- official reference for Config.json keys including scheduled shutdown and update shutdown settings.
• Unturned on Steam -- Unturned™ store page; the dedicated server tool is a separate product with App ID 1110390.
• Setting Up Your Server Panel -- the prerequisite installation guide for the Unturned™ dedicated server.
• Server Config Files: Commands.dat, Players.dat, Config.json -- the full Config.json field reference covering every key beyond the auto-restart subset.
• Workshop Content on Dedicated Servers -- the Workshop content loading system that the update-monitor checks for version changes.
• Server Codes Reference -- the next article covering the server code passcode system that enables direct-connect joining.

Is there any way to delay or skip a scheduled shutdown without editing Config.json?

No. The Config.json keys are read once at server startup and are not re-read dynamically. If you need to skip a scheduled shutdown on a particular day -- for example, during a planned community event that runs past the normal shutdown time -- you must either stop the wrapper script before the shutdown time (so the server does not restart) or edit Config.json to disable Enable_Scheduled_Shutdown and restart the server, then re-enable it the following day. There is no in-game command to postpone a shutdown.

What happens to players who are in a vehicle when the shutdown executes?

Players in vehicles are disconnected like any other player. Their vehicle is saved to the server's vehicle state, and the vehicle persists across the restart. The player's character position is saved at the last auto-save point before the shutdown. If the vehicle was in motion at the time of the disconnect, the vehicle stops at its last saved position and the player reconnects at that location.

How do I verify that the server's workshop update monitor is actually polling?

The server's console logs do not include a dedicated "polling for updates" message. The only indication that the update monitor is active is when it detects an update and begins the shutdown sequence. To verify the monitor is working, publish a minor change to a Workshop item that the server has subscribed to (or make a test Workshop item), submit an update, and observe whether the server initiates an update-triggered shutdown within approximately 30 minutes. If the server does not detect the update, verify that Enable_Update_Shutdown is true and that the server's Steam account has ownership or access to the Workshop items.

Can the wrapper script be configured to not update the server but still restart it?

Yes. Remove or comment out the SteamCMD update line from the wrapper script. On Windows, remove the start "" /wait "%~dp0steamcmd.exe" ... line. On Linux, remove the steamcmd +login anonymous ... line. The remaining loop just launches the server and restarts it after exit without updating. This configuration is appropriate for servers where the operator manages updates manually and only wants the wrapper script to handle the restart cycle.

Does the server need to be running on the preview branch to use update-triggered shutdowns?

No. The update-triggered shutdown system works on both the public and preview branches. The Update_Steam_Beta_Name key defaults to public and only needs to be changed to preview when the server is intentionally running the preview branch to test upcoming changes. The SDG documentation notes that the preview branch is for testing only and should not be used on production servers.

How do I migrate from a manual restart schedule to an automated one?

The migration process takes approximately 15 minutes for an experienced server operator: configure the Config.json keys, test the scheduled shutdown, deploy the wrapper script, verify one restart cycle, and announce the new schedule to players. The recommended approach is to run the manual restart as usual on the day of migration, deploy the wrapper script after the manual restart, and let the scheduled shutdown fire at the next configured time. This avoids the complication of coordinating the manual restart timing with the first automated restart.

Can the update-triggered shutdown be configured to ignore specific Workshop items?

No. The update monitor checks all Workshop items that the server has loaded. There is no allowlist or blocklist mechanism in Config.json to exclude specific items from update monitoring. If a specific Workshop item publishes updates so frequently that the update-triggered shutdowns become disruptive, the operator has three options: disable update-triggered shutdowns entirely (using only scheduled shutdowns), remove the frequently-updating item from the modlist, or contact the mod author to request less frequent updates.

Appendix E: Step-by-step Config.json edit checklist

Step	Action	Verify
1	Open Servers/<ServerName>/Server/Config.json in a text editor	File exists at the expected path
2	Add or uncomment Enable_Scheduled_Shutdown with value true	Key is present, value is lowercase true
3	Add Scheduled_Shutdown_Time with the desired 24-hour HH:MM time	Format is 04:30 not 4:30 or 4:30 AM
4	Add Scheduled_Shutdown_Warnings with comma-separated MM:SS intervals	No spaces between comma-separated values
5	Add Enable_Update_Shutdown with value true	Key is present, value is lowercase true
6	Add Update_Steam_Beta_Name with value public (or preview)	Key is present for clarity even if using default
7	Add Update_Shutdown_Warnings with comma-separated MM:SS intervals	Intervals total 5 minutes or less
8	Validate the JSON syntax with a validator or JSON-aware editor	No syntax errors reported
9	Restart the server to load the new Config.json	Server starts without errors
10	Create the wrapper script in the SteamCMD directory	Script is executable (Linux) or in the correct location (Windows)
11	Verify the wrapper script's server name matches the configuration directory	Name after +InternetServer/ matches directory name
12	Launch the wrapper script and verify the server starts	Server log shows normal startup sequence
13	Set shutdown time to 2 minutes ahead and verify the test works	Server shuts down and restarts through the wrapper script
14	Reset shutdown time to the intended value and restart	Schedule is on track for the intended time

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Full Config.json auto-restart reference, scheduled and update-triggered shutdown systems, wrapper scripts for Windows and Linux, interaction patterns, diagnostic table, FAQ, and integration guidance.

Authoring checklist

• [ ] Enable_Scheduled_Shutdown is set to true for production servers
• [ ] Scheduled_Shutdown_Time uses 24-hour HH:MM format (04:30 not 4:30 AM)
• [ ] Scheduled_Shutdown_Warnings includes at least three intervals with comma separation and no spaces
• [ ] Enable_Update_Shutdown is set to true for automated update handling
• [ ] Update_Steam_Beta_Name is set to preview if running on the preview branch
• [ ] Update_Shutdown_Warnings includes at least two intervals
• [ ] Wrapper script is deployed in the same directory as SteamCMD
• [ ] Wrapper script's +InternetServer/ name matches the server configuration directory name
• [ ] Scheduled shutdown has been tested by setting the time two minutes ahead and observing the console output
• [ ] Config.json syntax has been validated after every edit
• [ ] Server machine time zone is configured to match the majority of the player base
• [ ] Multiple server instances use staggered shutdown times at least 15 minutes apart
• [ ] Backup script integration into the wrapper loop has been tested and the backup files are confirmed non-empty
• [ ] Wrapper script timeout is long enough for both backup and SteamCMD to complete

Appendix F: Common Windows batch script errors and resolutions

Error message	Cause	Resolution
'steamcmd.exe' is not recognized as an internal or external command	The script is not in the same directory as steamcmd.exe	Move the batch script to the SteamCMD directory, or use an absolute path to steamcmd.exe in the script
The system cannot find the path specified	The %~dp0steamapps\common\U3DS path does not exist	Confirm SteamCMD has completed at least one successful update of App ID 1110390 and that the U3DS directory was created
Access is denied	The batch script is running without administrator privileges	Run the command prompt as Administrator, or move the SteamCMD installation to a directory that does not require elevation
The process cannot access the file because it is being used by another process	SteamCMD or the server is already running when the script tries to start a second instance	Kill any existing SteamCMD or server processes before starting the wrapper script
Timed out waiting for server to start	The server is taking longer than expected to initialize	Increase the timeout value before the goto loop command, or check the server logs for startup errors

Appendix G: Common Linux bash script errors and resolutions

Error message	Cause	Resolution
steamcmd: command not found	SteamCMD is not in the system PATH	Use the full path to steamcmd (e.g., /usr/games/steamcmd) or add the steamcmd directory to the PATH
No such file or directory when sourcing ServerHelper.sh	The symbolic link to U3DS does not exist or points to the wrong location	Verify the symbolic link with ls -la ~/U3DS and recreate it if necessary
Permission denied when executing the script	The script file does not have execute permission	Run chmod +x ~/MyServer.sh to add the execute permission bit
screen: command not found	Screen is not installed on the system	Install screen with apt install screen (Debian/Ubuntu) or yum install screen (RHEL/CentOS)
Cannot open display when server starts	The -nographics flag might be missing in the server launch command for non-screen environments	Verify the source ServerHelper.sh command does not include GUI-related flags; the default ServerHelper.sh should handle this

Cross-references

• Server Config Files: Commands.dat, Players.dat, Config.json -- the full server configuration reference; the auto-restart settings documented in this article are a subset of the Config.json keys covered in the broader reference.
• Workshop Content on Dedicated Servers -- the Workshop content loading system that the update-monitor checks for version changes.
• Server Codes Reference -- the next article in the server-config series; covers the server code passcode system.
• Setting Up Your Server Panel -- the prerequisite installation guide; completing this guide provides a working server to configure with the auto-restart settings.
• Unturned on Steam -- Unturned™ store page; the dedicated server tool is App ID 1110390.
• Smartly Dressed Games modding documentation -- official SDG documentation for server configuration and auto-restart settings.

The auto-restart system documented in this article is the foundation of reliable server maintenance. Combined with the Workshop content loading system covered in the next prerequisite article and the server code system covered in the following article, it forms the operational backbone that keeps a production Unturned™ dedicated server running with minimal manual intervention.

Every server operator should configure the auto-restart system before the server reaches double-digit concurrent players. The system is simple to set up, requires no plugins, and prevents the most common class of long-running server problems. A server that restarts on a predictable schedule is a server that players can trust to be available and responsive when they connect. The few minutes of configuration time required to enable the system pay back many times over in reduced operational overhead and improved server stability across the lifetime of the server. Server operators who invest this small upfront effort will never need to remember to restart their server manually, will never need to apologize to players for a server that has been running for a week and is showing performance degradation, and will never face the dilemma of choosing between an inconvenient manual restart and leaving a drifting server online.