Scheduled restarts: cure or bandage

Almost every long-running game server restarts on a schedule, and almost every discussion about it is an argument between two camps who are both right about different servers.

The useful question is not whether scheduled restarts are good practice. It is what yours is doing: buying you headroom you have chosen not to need, or hiding a fault that is getting worse.

The honest case for restarting

Game servers accumulate. Entity counts drift up, caches fill, fragmented memory forces the collector to work harder, and third-party code holds references it should have released.

You did not write most of that code and you are not going to fix it. A restart at 06:00 resets all of it, costs nothing when nobody is connected, and is cheaper than auditing thirty plugins you did not write. That is a legitimate engineering trade, not a failure.

The tell that distinguishes them

Frequency, and the shape of the decline.

Once a day, and performance is flat between restarts. That is maintenance. Nothing is wrong. Keep doing it.

Every four hours, and performance degrades noticeably by hour three. That is a leak, and the schedule is hiding it. The interval will keep shrinking, because whatever is leaking is not getting better, and one day four hours will not be enough.

The second case is the one worth acting on, and the action is measurement rather than a shorter interval. Watch memory across a full cycle: a leak climbs and never comes down, while normal operation sawtooths as the collector works. That distinction is visible in an hour of monitoring and invisible from the console.

Warn people, properly

A restart that drops forty players without notice costs more than it saves. The warnings people actually need are at fifteen minutes, five minutes, one minute, and ten seconds.

Fifteen minutes is the important one. It is long enough to finish a fight, get to a safe place, or bank what you are carrying. Five-minute warnings alone produce a scramble, and thirty-second warnings produce lost inventories and a grudge.

On a roleplay server the number is higher, because a scene takes longer to close than a dungeon run. Ask your players what they need rather than guessing.

Pick the hour from your own data

The default advice is "overnight", which assumes your players share your timezone. Many servers have populations that peak while the owner is asleep.

The right hour is the one with the fewest players, which is a question your own logs answer and nobody else's advice can. A server restarting at 04:00 local time because that is when the owner is asleep, while its actual population is European and playing, is restarting into its second peak, and the affected players will read that as the server being unreliable rather than as scheduled.

Restarting does not reset the thing people assume it does

A restart clears memory. It does not clear anything written to disk, which is where most of the state that actually misbehaves lives — a corrupted region file, a database table that has grown to millions of rows, a log directory filling the disk.

So a server that is slow again within an hour of restarting is telling you the problem is not in memory at all. That is a useful signal and it is routinely misread as "the leak is getting faster", which sends people to the wrong half of the system entirely.

The quick test is whether a restart helps for hours or for minutes. Hours means memory. Minutes means something persistent, and the console will not show it — it is the same class of problem as a plugin list nobody has audited accumulating work that never gets cleaned up.

The save is the part that matters

A restart is only safe if the world is written first. Most server software saves on shutdown, and most of the time that works.

The case it does not is the one where something is already wrong (a hung main thread, a disk that is full, a plugin blocking shutdown) and a forced kill after a timeout loses whatever was in memory. A manual save before the restart, or a save-then-wait in the restart script, closes that window for the cost of a few seconds. It is the same reasoning behind backups that have actually been restored rather than merely scheduled.

What a restart actually costs, which is not zero

The argument for restarting more often treats it as free. It is not, and the costs are the reason a schedule should be as sparse as the server can tolerate.

Everybody currently playing is interrupted. Even with warning, a restart ends whatever was in progress, and on a survival or roleplay server that is frequently the whole reason somebody logged in.

Cold start is slow. Chunks unload, caches empty, and the first ten minutes after a restart are the worst-performing ten minutes of the day, which is the opposite of what the restart was supposed to achieve.

It is a window for failure. A server that is running is not going to fail to start. A server that restarts four times a day gives itself four opportunities to discover a disk full, a port still bound, or a plugin that no longer loads, and it will find one of them at three in the morning.

The net position is that a restart is worth it when it prevents something worse, which is what makes the distinction between a cure and a bandage a practical question rather than a philosophical one.

What a good schedule looks like

Once daily, at your genuine off-peak hour, with warnings from fifteen minutes out, preceded by an explicit save, and monitored so that if you ever need to shorten the interval you find out why rather than just doing it.

And one rule worth holding: if the interval has shrunk twice, stop shortening it and go find the cause. That second shortening is the moment a maintenance habit has become a symptom nobody is treating, and symptoms that get managed rather than diagnosed are how servers end up quietly declining while every individual decision looked reasonable.