Search the Community

Automatic restarts live in the Scheduler tab of your instance: click New task, choose Restart (controlled), and set it to run daily at a quiet hour or every few hours. The task drives the same warning-and-kick engine as the manual Controlled Restart button, so players get a broadcast countdown before anyone is disconnected. The same tab runs Stop and Start tasks for planned downtime and RCON message tasks for repeating in-game announcements — your rules, your Discord, your wipe date. Every time you enter is in your own time zone, not UTC. On this page Open the Scheduler tab and read the task tableCreate a task and choose its typeSet the schedule in your own time zoneTune the restart warning ladderUse Stop and Start tasks only for planned downtimeAdd repeating RCON broadcastsTest with Run now, then watch Next run and Last resultUnderstand how the schedule meets automatic updatesTroubleshootingFrequently asked questions Before you start The Manage scheduler permission. Instance owners have it; a sub-user without it sees a red banner reading You don't have permission to manage the scheduler on this instance.A working admin and RCON password. Warning broadcasts, the #lock, the kick and every RCON message task travel over BattlEye RCON, so if that password is wrong the schedule still fires but nobody hears anything. Set it in Settings → Server & RCON Authentication.The server has to be running when a restart task fires. A controlled restart against a stopped server fails by design.Ideally, automatic backups already on, so a bad night is recoverable — see automatic backups and restore. 1. Open the Scheduler tab and read the task table Go to Instances → your instance → Scheduler. A fresh instance reads No scheduled tasks yet. Create one to automate restarts, start/stop, or RCON broadcasts. Once you have tasks, the Scheduled tasks card lists them all: ColumnWhat it tells youNameWhatever you called the task — also the name quoted in the Audit Log, so make it descriptive.TypeRestart, Stop, Start or RCON message.ScheduleA summary in your local time: Daily at 04:00, Every 6h, Weekly Sat at 05:00.Next runLocal date and time of the next fire. A disabled task shows a dash.EnabledAn On / Off switch. Flipping it saves at once and recalculates Next run.Last resultSuccess, Skipped or Failed from the most recent scheduled run. Hover a Failed value for the reason.ActionsEdit, Run now and a red trash button. Refresh re-reads the table; the page does not poll on its own. Deleting asks first and is blunt about it — This cannot be undone. To pause a task instead, switch Enabled to Off; its configuration survives. The Scheduler tab lists every automated task for one DayZ server, with its next run and the outcome of the last one. 2. Create a task and choose its type Click New task. The New scheduled task panel opens with a subtitle confirming that times are shown and entered in your local time, followed by the time zone your browser reports. Give it a Name — up to 128 characters; the placeholder suggests Nightly restart — then set Task type: Task typeWhat it does when it firesRestart (controlled)Queues a full controlled restart: warning broadcasts, #lock, an RCON kick of every player, then stop and start. This is the one for routine restarts.StopStops the server, optionally after a broadcast countdown. It does not kick players first.StartStarts the server. The server will be started at the scheduled time. No extra options.RCON messageBroadcasts one or more lines of global chat. Nothing else happens. Enabled is ticked by default. Finish with Create task — on an existing task the same button reads Save changes. An incomplete task is refused with the field at fault named: Name is required., Interval must be at least 5 minutes., Add at least one time of day. Careful: Task type is fixed at creation. Reopen a saved task and the dropdown is greyed out with Task type can't be changed after creation. Everything else stays editable. Wrong type means delete and recreate. The four scheduler task types — Restart (controlled), Stop, Start and RCON message — chosen once and fixed afterwards. 3. Set the schedule in your own time zone The Schedule card has one dropdown, Repeat, with three modes: Every N minutes — a rolling interval. Interval (minutes) has a floor of 5, and the hint says so. A round interval reads in hours in the table, so 360 minutes shows as Every 6h.Daily at time(s) — one or more fixed 24-hour HH:mm times, every day. Add time adds another; the trash icon drops one.Weekly on day(s) — the same time list, but only on the days you highlight with the Sun to Sat buttons. Every selected day gets every selected time. The Time(s) of day label names your browser’s time zone in brackets, and it means it: type 04:00 because you want four in the morning where you are. The panel converts to UTC for storage and back again for display. For restarts, prefer Daily at time(s). A daily schedule is anchored to the clock and never moves; an interval is measured from the last run, so it drifts across the day, and editing or re-enabling the task restarts its clock from that moment. A schedule worth copying on a populated modded server: TaskTypeScheduleScheduled restartRestart (controlled)Daily at time(s) — 04:00, 10:00, 16:00, 22:00Rules + DiscordRCON messageEvery N minutes — 30 Those four times are roughly every six hours, which suits a heavy mod list. A small or vanilla server is fine with one nightly restart at its quietest hour. Do not go shorter than four hours without a reason — every restart is real downtime. Careful: Times are converted to UTC when you save, using the offset in force that day. When your region moves on or off daylight saving, existing tasks shift by an hour in local terms — a 04:00 restart becomes 03:00 or 05:00. Open each task after the changeover and click Save changes to re-anchor it. Note: The panel checks for due tasks every half minute or so, so a task fires within about a minute of the time you set rather than on the exact second. Daily, weekly or rolling-interval schedules, entered in your local time zone and stored in UTC by the panel. 4. Tune the restart warning ladder Choose Restart (controlled) and a Restart process card appears. This is where a scheduled restart beats the button on Overview, which only offers three fixed windows. Warning broadcasts (before restart) is the countdown ladder, and it ships with five rows. These are the real defaults: Fires atDefault message10 minServer restart in 10 minutes.5 minServer restart in 5 minutes.3 minServer restart in 3 minutes.1 minServer restart in 1 minute.30 secServer restart in 30 seconds. Each row is a number, a min or sec unit and the exact text players see. Rewrite the wording, change the offsets, use Add warning for extra checkpoints, or remove rows with the trash icon. The largest offset sets the lead time for the whole run: leave 10 minutes at the top and a task set for 04:00 puts the server down at 04:10. Final warning (at restart time) — the zero-minute message. Default: Server restart is starting now. You will be kicked shortly.Kick reason — what each player is told as they are disconnected. Default: Server restart.Post-kick delay (s) — breathing room between the last kick and the stop, 0 to 60 seconds. Default 5, enough for the server to finish writing everyone out.Lock the server (#lock) before kicking players — ticked by default. Data loss risk: Leave the #lock checkbox ticked. Without it a player can connect while the server is emptying, spend thirty seconds loading in, then be cut off by the shutdown with nothing committed to persistence — exactly the lost-gear complaint you scheduled the restart to prevent. The lock does not survive the restart, so there is nothing to undo afterwards. Broadcasts are BattlEye global chat, so they land in the in-game chat box and nowhere else; that is why the ladder repeats rather than announcing once. A scheduled restart and a manual one run the same eleven-step engine and both show the same live Controlled restart card on this page — the full sequence is in restarting without rollbacks. The default warning ladder broadcasts at 10, 5, 3 and 1 minutes and again 30 seconds out before anyone is kicked. 5. Use Stop and Start tasks only for planned downtime Stop and Start are a pair, and they are not how you do a nightly restart. Use them when the server should genuinely be dark for a while — an overnight window on a private server, or a maintenance slot before a wipe. A Start task has no options. A Stop task gets a Stop warnings (optional) card: Warning lead (s) — how long before the stop the countdown begins. Default 60, and the hint is explicit: 0 = stop immediately.Broadcast every (s) — the gap between countdown lines, minimum 5. Default 30.Warning message — the template, defaulting to Server stopping in {seconds}s. The {seconds} placeholder becomes the seconds remaining, so a 60-second lead broadcasting every 30 sends Server stopping in 60s. then Server stopping in 30s. Data loss risk: A Stop task ends the game process without kicking anyone first, so any player still connected is disconnected by the process going away and reverts to the last state the server committed — position, health and inventory. Sixty seconds of warning is not much. If people might be online, schedule Restart (controlled) instead, or give the Stop task a lead of several minutes. A Stop task that fires on an already-stopped server records Skipped rather than failing, as does a Start task on a running one. Both also skip while another start, stop or restart is still in flight, which is what stops two schedules fighting each other. 6. Add repeating RCON broadcasts An RCON message task is the cheap way to put your rules and your Discord link in front of players without a mod. Pick the type and an RCON messages card appears with a single Broadcast line field. Add message gives you more lines. Interval between lines (s) — default 5 — is the gap left between them, so one task delivers a short block of announcements in order instead of dumping them at once. The schedule controls how often the block repeats. Rules and support: discord.gg/your-invite Base raiding is allowed. Griefing empty bases is not. Scheduled restarts: 04:00, 10:00, 16:00 and 22:00 server time. Three lines five seconds apart on Every N minutes with 30 briefs every player twice an hour. Keep each line to one sentence: past roughly 480 characters it is truncated before sending, and long lines scroll out of the chat box anyway. Note: A broadcast task on a stopped server records Skipped with no error — there is nobody to talk to. Run now on a stopped server refuses outright with Server is not running; cannot broadcast. An RCON message task broadcasts a block of announcement lines in order, on whatever schedule you set. 7. Test with Run now, then watch Next run and Last result Run now executes a task immediately, whatever its schedule says. It does not move Next run and it does not touch Last result — that column only reports scheduled runs. You get a toast instead: Ran "<name>" now. for a stop, start or broadcast. Careful: Run now on a Restart (controlled) task does not restart anything immediately — it queues the whole ladder, so with the defaults the server goes down ten minutes later. The toast reads Controlled restart queued for "<name>". and a live Controlled restart card appears on the Scheduler page with an Abort button. On a Stop task, Run now skips the Stop warnings countdown entirely and stops the server at once. Day to day, two columns tell you whether your automation is healthy: Next run should always be a sensible time in the future. A past time that never clears means the task cannot be picked up, almost always because the instance is mid-update.Last result should read Success. Skipped is informational, but the same Skipped every night means the task never does anything. Failed carries its reason as a tooltip — hover it. Note: On a restart task, Success means only that the controlled restart was queued. The restart itself reports separately on the Controlled restart card and in the Audit Log, so a task can read Success while the restart it started ended in Restart Failed. The full history is in Audit Log filtered to Scheduler: Task Created, Task Updated, Task Deleted, Task Run Now, Task Executed, Task Skipped and Task Failed, alongside the per-stage restart entries from Restart Queued to Restart Completed. Staff actions are attributed by name — see staff permissions and API keys. Last result and Next run are the two columns to check when you want to know your automation is still working. 8. Understand how the schedule meets automatic updates Your instance already restarts itself for reasons unrelated to the Scheduler. With Auto game updates on, a new DayZ build triggers a stop, an update and a start; mods marked Auto-update do the same when their Workshop entry changes. Those workflows send their own countdown, prefixed [Auto-update], and it is short — about a minute. The two systems stay out of each other’s way: An update workflow will not begin while a start, stop, restart or broadcast command is still in flight for that instance. It waits and tries again on its next pass, so it never lands inside your warning countdown.Scheduled tasks do not fire while the instance is mid-update. The task stays due rather than being lost, so it runs as soon as the update finishes — a 04:00 restart that collides with an update happens a few minutes late instead of not at all. So the short update countdown is no argument against scheduling your own restarts. An update-driven restart fires when Bohemia or a mod author decides; your schedule is what gives players a predictable rhythm and ten minutes of warning. Run both, and publish your restart times in your server description, your Discord and one of the RCON message lines from the previous step. Careful: Do not use Run now on a restart task while the status pill reads Updating. The scheduler would have waited; a manual queue does not, and the restart fails reporting that the instance is not provisioned. Wait for Running to come back. Troubleshooting My scheduled restart shows Skipped and the server never restarted Why it happens. A restart task will not queue a second controlled restart while one is still running on the same instance, and records Skipped noting that a restart process is already active. Two restart tasks set too close together do this to each other, and so does a manual Controlled Restart that is still counting down when the task fires. How to fix it. Open Scheduler and look at the Controlled restart card — a live run has a countdown and an Abort button, so let it finish or abort it. Then space restart tasks at least as far apart as the lead time of the warning ladder: with the ten-minute defaults, never less than fifteen minutes. The task says Success but the server did not restart Why it happens. Success on a restart task means the restart was queued, not that it completed — it then runs as its own process and can fail on its own terms. The two common causes are that the server was not running when the countdown ended, and that RCON could not authenticate, so the lock and kick step timed out. How to fix it. Read the Controlled restart card on the Scheduler tab: the failure reason is at the top and the timestamped detail is under Step log. Cross-check Audit Log filtered to Scheduler for Restart Failed. If RCON is at fault, re-check the password in Settings → Server & RCON Authentication — 4 to 10 characters, letters and numbers only. My tasks started firing an hour early after the clocks changed Why it happens. You enter times locally and the panel converts them to UTC when you save, using the offset that applied that day. UTC does not observe daylight saving, so when your region shifts, the stored time stays put and the local time you see moves by an hour. How to fix it. After a daylight-saving change, open each task and click Save changes without altering anything — that re-converts the times using the new offset, and the Schedule and Next run columns will read what you want again. Next run is a time in the past and the task never fires Why it happens. Tasks are only picked up for an instance that is fully provisioned and not mid-update. During a game or mod update the task keeps its old Next run rather than being skipped, which is deliberate — it runs when the update finishes. How to fix it. Check the status pill on Overview. Updating means wait it out; the task fires shortly after the pill returns to Running. Click Refresh to re-read the table. If the instance is Running and a task has been due for a long time, open a ticket with the task name. Nobody sees the broadcasts from my RCON message task Why it happens. Broadcasts are BattlEye global chat and nothing else, so they only appear in the in-game chat box. Skipped means the server was not running when the task fired. Success with nothing visible means the panel accepted the messages but RCON could not deliver them — nearly always a wrong RCON password. How to fix it. Open the RCON tab, confirm it connects and send a test message by hand. If it will not connect, fix the password in Settings → Server & RCON Authentication first — the scheduler uses the same one. More detail is in RCON, bans, whitelist and priority queue. Frequently asked questions How often should I restart my DayZ server? Every four to six hours suits a populated server with a heavy mod list, which is four times a day on a Daily at time(s) schedule. A small or vanilla server is usually happy with one restart at its quietest hour. DayZ servers degrade over long uptimes, but each restart is also real downtime, so anything shorter than four hours needs a specific reason. Are scheduler times UTC or my local time? Your local time. The task editor says so in its subtitle and names your browser’s time zone next to the Time(s) of day field. You type the time you want, the panel converts to UTC for storage, and the Schedule and Next run columns convert back. The one thing to watch is daylight saving — re-save your tasks after the changeover. Can I change a task from Stop to Restart after creating it? No. Task type is locked once the task exists, and reopening it shows the dropdown greyed out with Task type can't be changed after creation. Delete the task and create a new one with the right type. Everything else stays editable, including the schedule, the warning ladder and the message text. What is the shortest interval a scheduled task can use? Five minutes. Every N minutes will not accept less and rejects it with Interval must be at least 5 minutes. The floor protects you from yourself: a restart cycle tighter than its own warning ladder would leave players permanently mid-countdown. Do I need separate Stop and Start tasks for a nightly restart? No, and you should not use them for that. One Restart (controlled) task warns players, locks the server, kicks everyone cleanly and brings it back by itself. Stop and Start pairs are for genuine downtime windows, because a Stop does not kick players first and risks the rollbacks a controlled restart exists to prevent. Will a scheduled restart clash with an automatic game or mod update? No. An update workflow will not start while any start, stop, restart or broadcast command is in flight for your instance, and retries on its next pass. In the other direction, scheduled tasks do not fire mid-update; they stay due and run as soon as it finishes, so a collision costs you a few minutes rather than the restart. Related guides Getting started with the control panelRestarting without rollbacks

Every DayZ server restart kicks every connected player — there is no way around that, and any host who tells you otherwise is selling something. What you can control is whether players are warned in time to reach somewhere safe and whether they are disconnected cleanly, because a clean disconnect is what makes DayZ write each character to persistence. That is the whole difference between a routine restart and a wave of tickets about lost gear. In the DZSERVERS.HOST panel that job belongs to Controlled Restart on the Overview tab: it broadcasts a countdown, locks the server with #lock so nobody joins mid-shutdown, kicks everyone through RCON, then stops and starts the instance while you watch an eleven-step timeline. This guide walks the whole sequence and shows what to do when it goes wrong. On this page See who is online, then pick a warning windowStart the Controlled RestartTell your players what to do with the warningWatch the eleven-step timelineAbort while you still canConfirm the server is back, then clear the cardCheck the Audit Log trailAutomate it so you rarely do this by handTroubleshootingFrequently asked questions Before you start The server must be Running. Controlled Restart is greyed out on a stopped instance — there is nothing to warn anyone about.The Start / stop / restart permission. Instance owners have it; sub-users need it granted under Members.A working admin and RCON password. The warnings, the lock and the kick all travel over BattlEye RCON, so if that password is wrong the restart cannot finish. Set it in Settings → Server & RCON Authentication — see getting started with the control panel.Ideally, backups already switched on in the Backups tab, so a bad night is recoverable rather than permanent. 1. See who is online, then pick a warning window Open the Players tab and switch to Online to see who is actually connected right now. An empty server needs no ceremony — a plain Restart is fine. Twenty people mid-raid need the longest warning you can give them. Controlled Restart offers three windows, and each one fires a different ladder of in-game broadcasts: WindowBroadcasts players receive5 minutes5 min, 3 min, 1 min, 30 s10 minutes10 min, 5 min, 3 min, 1 min, 30 s15 minutes15 min, 10 min, 5 min, 3 min, 1 min, 30 s Ten minutes is the sensible default for a populated server. Five is enough for a quiet one. Fifteen is for when you know a big fight or a base build is in progress and you would rather not be the reason it ends badly. Data loss risk: Do not use Stop or the plain Restart button while players are online. Both act immediately: Stop asks the game process to exit and force-kills it if it does not go quietly, and Restart does the same then starts it again. Nobody disconnects — the server simply vanishes from under them. Every connected character reverts to whatever the server last committed to persistence, which is exactly the “I lost my gear” rollback you are trying to avoid. 2. Start the Controlled Restart Go to the instance Overview tab. In the power control bar you will find Start, Stop, Restart, Controlled Restart and Update. Click Controlled Restart and a small menu drops down headed Warn players, then restart in: with three choices: 5 minutes, 10 minutes and 15 minutes. Pick one. The button briefly reads Queuing… and you get a confirmation such as Controlled restart queued (10 min warning). A live timeline card appears directly above the Overview card and stays there for the whole run. The button is unavailable in four situations, and the tooltip tells you which: Server is not running — start it first.A controlled restart is already in progress — only one can run per instance at a time.Cannot restart while an update is in progress — wait for the game-data update to finish.Instance not provisioned — the instance is not ready yet. Note: Nothing destructive happens the moment you click. The countdown, the lock and the kick are all still ahead of you, and you can call the whole thing off until the lock goes out. The Controlled Restart dropdown on the Overview tab — choose how long players get before the kick. 3. Tell your players what to do with the warning The broadcasts go out over BattlEye as global chat messages, so they land in the in-game chat box and nowhere else. Players with chat scrolled away, or sitting in a menu, can miss one. That is why the ladder repeats rather than announcing once. The default wording is deliberately plain — Server restart in 10 minutes. down through Server restart in 30 seconds., followed at zero by Server restart is starting now. You will be kicked shortly. Put this in your rules channel once and point at it forever. When a player sees a restart warning they should: Break contact. Do not start a fight, a raid or a heli crash run inside the warning window.Finish whatever is in their hands — a half-completed craft or an open inventory transfer is the easiest way to lose an item.Move somewhere they are happy to reappear: away from other players, away from infected, off a roof, out of the water.Log out normally before the kick if they want certainty. A manual disconnect and the panel’s kick both produce a clean disconnect, but leaving voluntarily means they choose the moment. The reason the panel kicks players rather than simply killing the process is that a kick is a normal disconnect as far as the DayZ server is concerned. The server runs its usual disconnect path and writes the character out. Pull the process instead and there is no disconnect to run, so the character falls back to the last state the server committed — position, health and inventory included. Careful: Aborting after the broadcasts have gone out does not un-send them. If you cancel, say so in chat yourself from the RCON tab, or half your players will log off anyway. 4. Watch the eleven-step timeline The card is headed Controlled restart with a note of who triggered it — (manual) for a button press or (scheduler) for a scheduled task. While the countdown is running it shows Restart in and a live clock such as 4m 05s. Once the lock is in place a locked badge with a padlock appears next to the title. Underneath, every stage of the process is listed in order. Completed stages turn green, the current one spins amber, and a failure marks the stage it died on in red. StepWhat is happeningQueuedThe request is accepted and waiting to be picked up.PreparingThe panel checks the instance is provisioned, running and has a resolvable RCON port, then fixes the exact restart moment so a queue delay cannot compress your warning window.Sending warningsEach broadcast in the ladder goes out at its scheduled offset.Final warningThe zero-minute message is sent.Locking server#lock is sent over RCON so no new player can join during the shutdown.Kicking playersThe panel queries the player list and kicks each slot with the reason Server restart, then waits out a short post-kick delay.Stopping serverThe game process is stopped now that nobody is connected.Starting serverThe process is started again.Waiting for onlineThe panel waits until the server answers queries or reports a server FPS figure, which is the real proof it finished loading.Unlocking#unlock is sent as a belt-and-braces measure. A fresh start is unlocked anyway — the lock does not survive a restart.CompletedThe run is finished and the instance is back in service. Expand Step log for the timestamped detail: which warning went out when, the result of the lock and kick step, and the exact reason for any failure. Two extra states never appear in the list because they replace it: Failed and Aborted. The live controlled restart timeline, counting down through its eleven steps with Abort still available. 5. Abort while you still can An Abort button sits at the top right of the timeline card during the first four steps only: Queued, Preparing, Sending warnings and Final warning. Click it and the run stops where it is, the card reads This restart was aborted before the destructive phase. and the server keeps running with everyone still connected. The moment the process reaches Locking server the button disappears, and the API will refuse a late attempt with The restart has entered its destructive phase and can no longer be aborted. That boundary is deliberate: once the lock and the kicks are in flight, stopping halfway would leave you with a locked, empty, still-running server, which is worse than either outcome. Note: If you genuinely need to cancel after the lock, let the restart complete. It ends with the server up, unlocked and accepting players — the cost is the downtime you were trying to avoid, not any data. 6. Confirm the server is back, then clear the card Watch the last three steps. Starting server and Waiting for online are where a modded server takes its time; the panel allows roughly two minutes for the stop, three for the start and five more for the server to answer, and it gives up and reports a failure rather than hanging forever. You are back in service when the timeline reaches Completed, the Server Status pill reads Running and Server FPS on the Overview tab reports a number again. Click Dismiss to clear the finished card. If it ended in Failed instead, the reason is printed at the top of the card and repeated in Step log. Read it before touching anything — Server did not stop in time. and Lock/kick step failed or timed out. point at completely different problems. A finished controlled restart with every step green and the step log expanded for the timestamped detail. 7. Check the Audit Log trail Every controlled restart writes itself into the Audit Log tab under the Scheduler category, so you can prove after the fact what happened and when. Filter to Scheduler and you will see the chain: Restart QueuedRestart: Locking ServerRestart: Kicking PlayersRestart: Stopping ServerRestart: Starting ServerRestart Completed, or Restart Failed / Restart Aborted This is the record that settles arguments. When a player insists they lost a backpack “in the restart”, the audit trail shows whether a controlled restart ran at all, whether it completed, and whether it was a member of staff who pressed the button. Actions taken by sub-users are attributed to them by name — see staff permissions and API keys. The Audit Log records every stage of a restart under the Scheduler category, with the staff member who triggered it. 8. Automate it so you rarely do this by hand Doing this manually is for one-off maintenance. Routine restarts belong in the Scheduler tab: click New task, set Task type to Restart (controlled) and give it a daily time or two. Scheduled runs use exactly the same eleven-step engine and show the same live timeline, and the Next run column tells you when the next one lands. A scheduled restart task exposes more control than the three-option dropdown does. Under Restart process you can: edit the Warning broadcasts (before restart) ladder outright — change the offsets, rewrite the text, or Add warning for extra checkpoints;set the Final warning (at restart time) message;set the Kick reason players see, and the Post-kick delay (s) breathing room before the stop;turn off Lock the server (#lock) before kicking players, though there is rarely a good reason to. Set the times to your quiet hours and you will mostly stop thinking about restarts. Full detail, including how the schedule handles time zones, is in automatic restarts with the Scheduler. Note: Restarts and backups solve different problems. A controlled restart prevents rollbacks; backups undo them. Turn both on — see automatic backups and restore. A scheduled controlled restart exposes the full warning ladder, kick reason and the #lock option. Troubleshooting Players lost gear or spawned back at an old position after a restart Why it happens. The server process was ended while they were still connected — a Stop, a plain Restart, a crash or a memory kill. Without a disconnect, DayZ never runs its save-on-disconnect path for those characters, so each one reverts to the last state the server had committed. Anything gained since then is gone, and items moved around in the meantime can end up existing in two places at once, which is where duping complaints come from. How to fix it. Use Controlled Restart from now on, and schedule the routine ones. For the damage already done, the Backups tab can restore Players DB on its own without touching world data — the server must be stopped to restore. See automatic backups and restore. Nobody saw the restart warning in chat Why it happens. Warnings are BattlEye global chat messages and nothing else. A player who joined between two broadcasts, had chat scrolled away, or was in a menu simply did not see one. If RCON itself cannot authenticate, none of them are delivered at all. How to fix it. Open the RCON tab and check the badge reads Connected. If it does not, re-check the admin and RCON password in Settings → Server & RCON Authentication — remember it is 4 to 10 characters, letters and numbers only. Then prefer a 10 or 15 minute window, and in a scheduled task add extra checkpoints with Add warning. The Controlled Restart button is greyed out Why it happens. Four conditions disable it, and the tooltip names the one that applies: the server is not running, a controlled restart is already in progress, a game-data update is in flight, or the instance is not provisioned yet. A sub-user without the Start / stop / restart permission does not see the power controls at all. How to fix it. Hover the button and read the tooltip. If a previous run is stuck showing as active, open the timeline card — a finished run needs Dismiss, and a live one needs Abort or has to be allowed to finish. For a missing permission, the instance owner grants it under Members. The restart ended in Restart Failed Why it happens. Each stage has its own deadline and reports its own reason. Lock/kick step failed or timed out. means RCON did not answer, which is almost always the password. Server did not stop in time. and Server did not start in time. usually mean a heavy modded load or a node under pressure. Server did not come online in time after start. means the process launched but never finished loading its mission. How to fix it. Read the reason on the card and the detail in Step log, then check the Live Logs card with Stream set to rpt for the boot tail. The panel does not abandon your instance: if it gave up after asking for a stop, it puts the instance back to running on its own, and if the lock was still held it queues an #unlock. Players cannot join and the server looks locked out Why it happens. A restart failed after #lock went out but while the server was still up, so the lock outlived the run. The panel tries to clear this automatically, but it cannot if RCON is unreachable — which is often the same fault that broke the restart. How to fix it. Open the RCON tab, click Connect RCON, and send #unlock. If RCON will not connect, fix the password first. A completed Controlled Restart also clears it, because a freshly started server is unlocked. More RCON detail is in RCON, bans, whitelist and priority queue. Frequently asked questions Does Controlled Restart avoid kicking players? No, and nothing can. A DayZ restart ends the game process, which disconnects everyone on it. What Controlled Restart changes is that players are warned on a repeating countdown, the server is locked so nobody joins into a shutdown, and each player is disconnected properly instead of having the server disappear from under them — which is what keeps their character state intact. What is the difference between Restart and Controlled Restart? Restart stops and starts the process immediately: no warning, no lock, no kick. It is the right tool on an empty server or when something is already broken. Controlled Restart adds the warning ladder, the #lock, the RCON kick and the live timeline, and it is what you should use any time somebody is connected. Why does the panel lock the server before kicking players? So that the server does not refill while it is emptying. Without the lock, a player can connect during the kick sequence, spend fifteen seconds loading in and then be killed by the shutdown with nothing saved. The lock is temporary in every sense: it does not survive the restart, the panel sends an #unlock as a final step anyway, and it is cleared automatically if the run fails while still holding it. How long is my DayZ server down during a controlled restart? Only the tail end of the process is downtime — the whole warning window is normal play. Actual downtime depends on your map and mod list, so watch the timeline rather than working to a fixed number: a heavily modded server takes substantially longer to boot than vanilla. What is fixed is when the panel gives up: it allows roughly two minutes for the stop, three for the start and five more for the server to answer before declaring a failure. Those are outer bounds, not the expected wait. Can I use Controlled Restart to save settings that need the server stopped? Not directly, because it always brings the server back up. Instance Settings still requires a stopped instance to save. The clean pattern is to run a Controlled Restart so players leave properly, then click Stop as soon as the timeline reports Completed, make your changes and start it again. Config detail is in every serverDZ.cfg setting explained. Can a controlled restart damage bases, vehicles or stashes? A clean shutdown will not. Player characters and world objects are stored separately under mpmissions/<world>/storage_*/, and a controlled restart lets the server close both properly. It is the abrupt kill that puts them at risk, which is one more reason not to reach for Stop with players online. Keep backups on regardless, because a restart is not the only thing that can go wrong. Related guides Getting started with the control panelAutomatic restarts with the SchedulerRCON, bans, whitelist and priority queue