Announcing server maintenance to players

Tell players about planned maintenance at least a day ahead, with the exact start time in their own timezone, how long it will take, what changes, and whether they need to do anything. Remind them an hour before, warn in game at ten, five and one minute, and post again the moment the server is back. For unplanned downtime the order reverses: acknowledge it within minutes even if you do not know the cause, post an update on a fixed cadence until it is resolved, never promise a time you cannot keep, and finish with a short note on what happened. Players forgive downtime far more readily than silence, and most of the warning work can be automated so it happens even when you are busy.

Restarts themselves - when they help and when they only hide a problem - are covered in restart schedules that help. This post is about the people on the other end.

Planned and unplanned downtime need different messages#

Most communities are good at the first column and bad at the second. A planned update gets a polished announcement; a crash at 21:00 gets nothing for forty minutes while the owner fixes it, and by then a dozen people have asked in chat and two have decided the server is dead. The fix is to treat the first message of an outage as part of the fix, not something to do after it.

What every maintenance announcement must say#

Five facts, in this order, and nothing a player has to work out themselves:

1. What - "Update to the new game version", "Monthly map wipe", "Moving to a bigger plan".
2. When - the start time in every reader's timezone, using a Discord timestamp.
3. How long - a realistic estimate, rounded up. "About 30 minutes" when you expect fifteen.
4. What changes - for players, not for you. "Clients must update before joining", "Inventories are kept, builds are wiped", "Nothing - this is invisible".
5. What to do - update the game, re-import the mod profile, nothing at all.

Maintenance: game update to version 1.2When: <t:1767294000:F> (<t:1767294000:R>)Expected downtime: about 30 minutesWhat changes: you need to update your game before rejoining.Worlds, inventories and builds are not affected.What to do: update through your launcher, then join as usual.We will post here when the server is back.

Discord renders <t:UNIX:F> as a full date and time in each reader's own timezone, and <t:UNIX:R> as a live countdown. Get the Unix time from any converter, or date -d "2026-01-01 20:00 CET" +%s on a Linux machine. The other formats are t and T for short and long time, d and D for dates, and f for short date and time.

Leave out everything else. Players do not need to know which config file you are editing. If there is a reason worth telling them - "the update fixes the crash on the bridge" - one sentence is enough.

When to announce#

Routine restarts do not need an announcement each time. Publish the schedule once - "the server restarts every day at 05:00 CET" - pin it, and let the in-game warnings handle the rest. A ping for every routine restart trains players to mute the announcements channel, and then they miss the one that matters.

Wipes are different. Players plan around them, sometimes for weeks, and a wipe moved or announced late costs more goodwill than almost anything else you can do. Wipes without losing your players is mostly about this.

Avoid starting maintenance at your peak hour. Your player-count history shows when the server is quietest - often early morning in the server's timezone - and that is when routine work belongs. For a server in Germany, early morning CET is also late evening in the Americas, so check whether a part of your community plays then.

Warning players in game#

A Discord announcement reaches people who read Discord. The in-game countdown reaches the people who are about to lose their progress. Most games have a console command that broadcasts to everyone:

tellraw @a {"text":"Server restarting in 5 minutes - find somewhere safe.","color":"gold"}title @a actionbar {"text":"Restart in 1 minute","color":"red"}

Palworld's admin Broadcast command also exists; on some versions it mangles spaces in the message, so test it before relying on it. Whatever the game, send the warnings at fixed offsets - ten minutes, five, one - and say whether progress is safe. "The world saves before the restart" stops people logging out in a panic in the middle of a fight.

The last warning should go out shortly before the server stops, not at the moment it stops, and the stop itself should be a clean one that saves the world. A kill does not save. Graceful shutdown and health checks explains the difference.

Automating the countdown with a schedule#

A restart that relies on someone typing warnings at 05:00 will eventually happen without them. Put the whole sequence in a schedule: warnings, a pause, a backup, the restart.

On RE:NODE the Schedules tab takes a cron expression and an ordered list of tasks, each with a delay: a console command, a backup, or a power action. A daily restart with warnings looks like this:

1. Console command   say Restarting in 10 minutes. The world saves first.   delay 02. Console command   say Restarting in 5 minutes.                          delay 300 s3. Console command   say Restarting in 1 minute.                           delay 240 s4. Console command   save-all                                              delay 50 s5. Backup                                                                  delay 10 s6. Power action      restart                                               delay 0

Adapt the commands to your game from the table above; save-all is Minecraft's, and other games either save on a clean stop or have their own save command. Check which timezone the schedule runs in before trusting the hour, and remember that the five fields are minute, hour, day of month, month and day of week - cron expressions explained has the details and the common mistakes. More schedules worth setting up are in scheduled tasks worth having.

FiveM servers usually leave restart warnings to txAdmin, whose scheduled restarter announces upcoming restarts to players on its own. Do not run two restart schedules on the same server; the second one will restart a server that just came up.

Automation also covers the "it is back" message. A webhook that posts when the server stops and when it starts gives players a status channel that updates itself, at two in the morning, without anyone awake. Discord webhooks for server status has the setup.

When it goes down without warning#

The first message is about speed, not information. Within a few minutes of noticing:

The server is down. We know, and we are looking at it.Next update by <t:1767297600:t>, sooner if it is fixed.

Then keep the promise. Post on the cadence you named - every 30 minutes is reasonable - even when the update is "still working on it, no new information". A channel that has said nothing for an hour reads as abandoned.

What not to do:

• Do not give a time to fix before you know the cause. "Back in 10 minutes" that becomes two hours is worse than no estimate.
• Do not guess at the cause in public. "We are being attacked" or "the host is down" said on a hunch is often wrong and hard to take back.
• Do not blame anyone - a player, a mod author, a host. Even when it is true, it reads as deflection.
• Do not go quiet while you fix it. Ask a trusted member of staff to handle the updates if you need both hands.

Check your own side first: the console log and the resource graphs will usually say whether it is a crash loop, a memory limit or something outside the server. Why your game server keeps restarting covers reading those. RE:NODE publishes a status page at /status, which is the place to look before assuming the problem is yours or the host's. On RE:NODE, a server that crashes three times in an hour also gets a warning on its server page and an automatic support ticket, so a crash loop does not go unnoticed even if you are asleep.

After it is back: the closing message#

The closing message is the one players remember. Post it as soon as the server accepts connections, not after you have finished tidying up.

The server is back. Downtime was about 45 minutes.What happened: an update to a plugin failed to load and stopped the server.What we did: rolled it back from the backup taken before the update.Lost progress: none - the backup was from 10 minutes before the restart.What changes: the plugin stays on the old version until it is fixed upstream.

For planned maintenance, the closing message is a changelog: what changed, what players need to do, and anything that behaves differently. For an outage, it is a short post-incident note: what happened, what you did, whether anything was lost, and what you are changing so it does not happen again. Three to five sentences. A detailed technical write-up can go in a separate channel for those who want it.

If progress was lost, say how much, plainly. "Everything after 20:40 is gone" is better than discovering it. Restoring from a backup means everything since that backup is lost, which is why backups shortly before every maintenance window matter - backups that actually restore covers why the restore half deserves practice.

Big changes: version jumps, wipes and moves#

Some maintenance changes what players have to do to keep playing, and those announcements need more than a time and a duration.

A version jump - a major game update, a new modpack version, a Minecraft release - means every player must update their client, and modded players may need a new profile or pack. Say exactly which version to be on, link the pack or profile, and say whether the world carries over. If mods have not caught up with a game patch yet, say that the server is deliberately staying on the old version and roughly when you will review it; players on auto-updating launchers otherwise assume you have forgotten.

A wipe needs the most notice of anything: what is wiped (map, inventories, blueprints, characters), what carries over, the exact time, and whether the old world will be downloadable or visitable. Post it at least a week ahead, repeat it at 24 hours and one hour, and never move it quietly.

A move to a new server or address needs the new address published before the old one goes away, and both working for a while if you can manage it. A domain name that you repoint, rather than a raw IP, makes this nearly invisible to players. Moving a server without losing players has the order of operations, including DNS timing.

A plan change on RE:NODE is the easy case: changing plan moves the limits on the server you already have rather than rebuilding it, so the address and world stay the same. It still involves a restart, which deserves the usual in-game warning.

Where the announcements should go#

One source of truth, mirrored elsewhere:

• The Discord announcements channel is the source. Make it an Announcement channel on a Community server and other Discords - a partner server, a list of your alliance's servers - can follow it.
• In game, for anything happening in the next ten minutes.
• The server's MOTD or description, for a known upcoming wipe date.
• Listing sites, if a long outage would otherwise show you as offline for days. Server listing and voting sites covers keeping a listing accurate.
• A status channel updated by a webhook, for up and down events.

Keep the announcements channel for announcements. If players can reply there, it becomes a support channel and the next notice is buried. Point replies to a support or chat channel instead.

FAQ#

How far in advance should I announce maintenance?

At least 24 hours for a short update, a week or more for a wipe or migration, with reminders an hour before and in-game warnings in the final ten minutes. Routine daily restarts only need the schedule published once and in-game warnings each time.

What time of day should maintenance happen?

When your player count is lowest, which your player history shows. For a server in Germany that is usually early morning CET, but check whether part of your community is in a timezone where that is prime time.

How do I warn players in game before a restart?

Use the game's broadcast command from the console - say in Minecraft and Source games, servermsg in Project Zomboid - at ten, five and one minute. Put the warnings in a scheduled task with delays so they run even when nobody is at the keyboard.

Should I give an estimate during an outage?

Only once you know the cause and the fix. Before that, promise the time of the next update instead of the time of the fix, and keep that promise even if the update says nothing new.

Do I need to explain what went wrong after an outage?

Briefly, yes. Two or three sentences on what happened, what was lost, and what you are changing build trust far faster than silence. Avoid blaming anyone and avoid technical detail most players will not read.

Should players be compensated for downtime?

It is not expected for a free community server, and promising it sets a precedent. A small in-game gesture after a long outage is a nice touch, but a clear explanation and no repeat matter much more.