DayZ Server Restart Schedule: How to Set One Up Safely

A DayZ server restart schedule can use the game’s messages.xml countdown or a host’s calendar scheduler. The difference matters: Bohemia’s XML can warn players and shut the server down, but it does not start the process again. A recurring restart needs a separate service or a hosting panel. This guide shows you where the file belongs, how to read Bohemia’s sample, and how to verify the shutdown and relaunch before you publish a schedule. It covers DayZ dedicated servers for PC; the Game Hosting option below is for Steam players only.

Choose a countdown or a calendar schedule#

Use messages.xml when the shutdown should happen after a set amount of server uptime and you manage the process that will bring it back. Use a calendar scheduler when the restart should happen at a particular local time, such as before your group’s usual evening session. These are different clocks, even when both eventually stop the same DayZ process.

Bohemia’s official Chernarus Central Economy sample messages.xml shows the XML countdown and shutdown fields. Its ten-hour deadline is an example, not a universal restart recommendation.

For a DayZ server on Steam for PC, we recommend Game Hosting when you want a timed restart managed in a panel. The DayZ schedule supports a safe restart, optional 5-, 15-, or 30-minute in-game warning, and waiting for the server to be empty. The panel is for PC (Steam) servers; it does not host Xbox, PlayStation, or Microsoft Store/Game Pass PC servers.

Find the messages.xml for the active mission#

The message file sits inside the mission folder the server is actually running. Bohemia’s Chernarus sample path is:

mpmissions/dayzOffline.chernarusplus/db/messages.xml

The folder name changes with the selected mission. Check the mission template in your active serverDZ.cfg before editing. Livonia, Sakhal, Nasdara, and community maps can use different mission names, and a file in the wrong folder may never be read. If your host manages mission files through a panel, use its file manager or documented access method to find the active mission. Don’t infer the path from a guide written for another map.

Before changing anything, make a separate copy of the exact messages.xml you found. Give the copy a name that includes the map and date, and keep it outside the file you are editing. If the file is absent, the official Central Economy repository can show the sample structure; do not overwrite another mission’s settings just to make the example path match.

Set a countdown that shuts the server down cleanly#

Bohemia’s sample uses a positive deadline to enable the countdown and shutdown set to 1 to stop the server when it reaches zero. The #tmin placeholder shows the minutes remaining. Here is the relevant shape from the official example:

<message>
    <deadline>600</deadline>
    <shutdown>1</shutdown>
    <text>#name will shutdown in #tmin minutes.</text>
</message>

600 means 600 minutes from the server’s start, or ten hours. It is an example value in Bohemia’s sample, not an officially recommended cadence. The official message system sends countdown messages at set points before the deadline; #tmin reflects the remaining time. Keep the tags and XML nesting intact if you add this to an existing file, and preserve any other messages already there.

1. Copy the active file

   Make a separate backup of the messages.xml in the mission the server currently uses.

2. Add or update one countdown

   Use Bohemia’s documented deadline, shutdown, and text fields. Treat the sample’s 600 minutes as an example until you choose a schedule for your own group.

3. Save and review the XML

   Check that the file still opens as XML and that you edited the active mission folder, not a spare copy.

This countdown only shuts the DayZ server down. It does not relaunch DayZServer or choose a calendar time. If your process manager is not set to start the server again after a graceful exit, the server will stay offline. Set up that separate behavior before relying on an automatic shutdown.

Arrange the relaunch as a separate task#

Think of a restart as two linked actions: DayZ closes cleanly, then another process starts it again. Bohemia’s XML sample handles the first part. A service manager or host schedule handles the second. If you only configure the countdown, you have scheduled a shutdown, not a repeating restart.

On a rented server, check whether the host’s scheduler performs a safe DayZ restart or merely sends a stop action. Read the labels carefully: “restart when empty” and “stop at 5:00” do not mean the same thing. A restart should preserve the existing server files, and its status should return to online after the process is launched again. If you self-host, use the process manager you already maintain and verify its relaunch behavior with a controlled restart; this guide avoids copying a batch file or command from another DayZ build.

Do not run an XML deadline and a second restart schedule at overlapping times until you understand how both timers behave. An uptime countdown and a local-time schedule can fire at different points after an unplanned crash or manual restart. Choose one source of timing for the same event, or test the interaction while the server is quiet and you have a current backup.

Choose a time that fits the group#

There is no official DayZ restart interval that fits every community. A solo player who rarely meets friends may care more about a predictable return than frequent warnings; an active group may want to avoid interrupting its regular play window. Pick a time that gives players a chance to reach a safe place, then post it where your group actually checks for server notices.

Keep the scheduling mechanism in mind:

• An XML deadline is measured from the server process starting. If the process starts at a different time after maintenance, the next shutdown follows that new start.
• A host-panel schedule follows the time selected in the panel. Confirm whether the panel uses your device’s local time or another time zone before announcing the hour.
• A restart after an update or maintenance may not match the schedule you told players. Check the current server status before they join.

You may see specific intervals suggested elsewhere, but they are operator choices unless Bohemia documents them. The current SERP also repeats broad restart durations and performance claims without primary evidence. Don’t promise that a particular interval will fix lag, refresh loot, or prevent crashes. Use an interval your community can live with and change it only when you have a clear reason.

Verify one planned shutdown before posting the schedule#

Test the exact method you chose before making it a standing expectation. Pick a quiet time, make sure the active mission file has a backup, and keep a way to reach the host panel or process manager if the server stays offline. A successful countdown does not prove the relaunch step is configured.

1. Check the selected mechanism

   Confirm that the schedule points to the active DayZ server and the intended mission. If you use a panel, verify the displayed time zone and warning setting.

2. Observe the shutdown warning

   Stay in game or ask one player to watch the message. Confirm it appears before the server closes; don’t assume a saved XML edit or panel form means the warning was sent.

3. Confirm the process returns

   Check the server’s status and its current logs after the shutdown. If it remains offline, look at the separate relaunch service or host task rather than deleting persistence files.

4. Tell players the verified time

   Announce the time and time zone you observed, and explain what players should do before the shutdown.

A restart duration depends on the server and what it is doing; there is no verified fixed number to promise. A shutdown or restart is also different from a full wipe. If your group is worried about losing a world, keep backups current and check the server’s recovery options before changing any files. For settings that also need a restart, see the guide to DayZ server settings by goal.

If the log reports a shutdown but the server does not come back, fix the relaunch task before adjusting the countdown. If the warning never appears, re-check the active mission path and the saved schedule. Keep changes small: adjust the timer or one scheduling mechanism, then verify again.