Automating Server Restarts Without Annoying Everyone

Somebody notices the server feels sluggish. Somebody else says restart it. It gets restarted, everything is fine for three days, and the cycle repeats. Eventually the owner sets up a nightly restart and stops thinking about it, usually at whatever time seemed reasonable when they wrote the cron line.

That last decision is worth more thought than it gets, because a restart at the wrong hour is a small self-inflicted outage repeated every single day.

Why servers need restarting at all

Memory fragmentation and leaks. Long-running processes accumulate memory they cannot reuse. Java servers are particularly prone to this, and a Minecraft server that has been up for two weeks frequently uses considerably more memory than the same server after a restart, doing the same work.

Entity and object accumulation. Games with persistent worlds accumulate things, dropped items, spawned entities, temporary objects that were never cleaned up. Each one costs simulation time every tick.

Plugin state drift. Some plugins hold caches that grow, or handles that are never released. Well-written ones do not. Most servers run at least one that is not well-written.

It masks problems, which is the honest catch. A nightly restart makes a memory leak invisible, and invisible problems do not get fixed. If your server is unplayable after eighteen hours and fine after a restart, the restart is a workaround and something specific is wrong. Diagnosing a crash and reading your logs are how you find it.

The reasonable position: schedule a restart because it is cheap insurance, and also notice if you ever need one.

Choosing the hour, which is the actual decision

Most owners pick a time that sounds quiet. Most owners are wrong about their own server.

Look at the measurement, not your intuition. Your peak-hours chart shows the real shape of your day, and it is frequently one to three hours from where the owner assumed: because owners see a full server whenever they play, and they play at the same time every day.

Restart in the deepest trough. Usually somewhere between 4am and 7am in whatever timezone your community lives in, which may not be your own.

Check the weekend separately. A time that is dead on Tuesday may not be on Saturday.

Avoid the hour just before your peak. A restart that overruns eats the start of your busiest period, which is the most expensive time available.

The difference between a well-placed and a badly-placed restart is not small. Ten minutes of downtime at 5am costs almost nothing. The same ten minutes at 8pm costs you the arrivals, who do not come back to check.

Warning people properly

A restart nobody knew about is an outage. A restart with warnings is a pause.

The cadence that works: fifteen minutes, five minutes, one minute, thirty seconds. Four messages, escalating.

Fifteen gives someone time to finish what they are doing. Five gives them time to get somewhere safe. One and thirty seconds stop anyone starting something new.

Say why, once. "Scheduled restart in 15 minutes — routine, back in about two." People tolerate scheduled maintenance enormously better than unexplained downtime, and the word "scheduled" does most of the work.

Put the schedule somewhere permanent. In the message of the day, in your Discord topic, in your server description. A player who knows the server restarts at 5am nightly is never surprised by it.

Save first, if the game needs it. On persistent-world games the warning sequence should end with an explicit save before the stop. Losing ten minutes of building to a restart is worse than the restart.

Implementing it

With systemd, a timer unit is the tidy answer, because everything stays in one place and logs consistently:

# /etc/systemd/system/mygame-restart.timer
[Unit]
Description=Nightly restart of mygame

[Timer]
OnCalendar=*-*-* 05:00:00
Persistent=true

[Install]
WantedBy=timers.target

paired with a service that stops and starts it. Keeping a game server running covers the service side, and doing the restart through systemd means it also honours your clean-stop configuration rather than killing the process.

With cron, the traditional answer, which is fine:

0 5 * * * systemctl restart mygame

With the game's own scheduler, where one exists. Many games and many admin plugins have a built-in restart scheduler with warning messages included, and if yours does, use it, it handles the announcements for free.

With RCON, for the warnings: a small script that sends the countdown messages and then issues a save and stop. RCON explained covers the protocol.

The mistakes

Restarting during peak. The big one, and it is almost always because nobody checked the chart.

No warning. Costs you whatever people were doing and a measure of goodwill each time.

Restarting too often. Every four hours is not maintenance, it is an admission that something is broken. Find the leak.

No clean stop. Killing the process instead of asking it to stop loses unsaved state and occasionally corrupts a save. Set TimeoutStopSec generously and use the game's own stop command where possible.

Restarting and not checking it came back. A restart that fails is worse than no restart, because you are now down for eight hours instead of two minutes. Anything automatic needs monitoring that tells you when it did not work.

Stacking a restart with an update. Tempting and wrong. A restart is routine; an update is a change. Doing both at once means a failure has two candidate causes. Updating without breaking things covers the discipline.

How it shows up from outside

Worth knowing, because a scheduled restart is visible to anyone reading your listing.

A server queried every fifteen minutes will occasionally be caught mid-restart, and that appears as a gap in the uptime history. A two-minute restart is usually missed entirely; a ten-minute one shows up most nights.

The pattern matters more than the total. A gap at the same time every day reads as a scheduled restart, which is a sign of a maintained server. Scattered irregular gaps read as instability. How these figures are produced covers what is being recorded.

If your restart is producing a visible nightly hole, either it is taking longer than you think; worth measuring, or it is placed at an hour where the sweep reliably catches it.

How often, by game type

The right interval varies more than people assume, and defaulting to nightly is sometimes overkill and sometimes not enough.

Round-based servers — deathmatch, surf, prop hunt, arenas. Frequently need no scheduled restart at all. Nothing persists, memory use is flat, and these servers routinely run for months. Restart when you update, and otherwise leave them alone.

Survival and building games. Nightly is the usual answer. Entities accumulate, chunks stay loaded, and the memory curve is real.

Heavily modded servers. Nightly, sometimes twice. The more code is running, the more of it holds onto something it should have released.

FiveM and script-heavy platforms. Frequently restarted several times a day, because resource-heavy servers degrade noticeably over hours. This is close to standard practice in the roleplay community and players expect it.

Anything with an economy or a database. Nightly, and make sure the restart includes a proper save. Databases for game servers covers why a hard kill is worse here than elsewhere.

The honest test: measure. Note the memory use an hour after a restart and again eighteen hours later. If it has barely moved, you do not need a nightly restart and are taking a small outage every day for nothing. If it has doubled, you have found the interval, and possibly a leak worth chasing.

Restarting without a full restart

Some of what a restart buys can be had without taking the server down, and it is worth knowing which.

Reloading a plugin rather than the whole server. Many admin frameworks support it, and it is the right tool for a config change. It is not the right tool for a version change, a plugin reloaded onto a running server frequently leaves the old version's state behind, which produces bugs that survive until an actual restart.

Clearing entities. Most of the accumulated cost on a survival server is dropped items and stray entities. A scheduled cleanup command removes them without disconnecting anybody, and on some servers it is enough to remove the need for a nightly restart entirely.

Unloading distant chunks or regions. Games with a persistent world usually keep more loaded than they need. A periodic unload reclaims memory quietly.

Rotating logs without stopping. logrotate handles this, and an unrotated log filling a disk is one of the reasons servers get restarted "to fix" something unrelated.

None of these replace a restart entirely. Together they frequently move you from needing one daily to needing one weekly, which is a real reduction in visible downtime.

Setting it up once

1. Look at your actual peak-hours chart and find the real trough.
2. Time a manual restart. Not an estimate; how long from stop to accepting connections.
3. Configure the warning sequence, four messages, ending with a save.
4. Schedule it through systemd, cron, or the game's own scheduler.
5. Publish the time in the description and the Discord.
6. Watch it for a week, and confirm the server came back each night.

Then leave it alone. It is one of the few pieces of server maintenance that is set and forget, once the hour is right.