Restart schedules that help, and ones that just interrupt

Scheduled restarts are close to universal in game hosting and are usually treated as hygiene, like clearing the logs. They are really a workaround: something is degrading over hours, and restarting resets it. That is a perfectly legitimate thing to do. It is only a problem when nobody writes down what is degrading, because then the restart becomes load-bearing, the interval creeps from weekly to nightly to every six hours, and the actual fault is never found.

So the question is not "should I restart nightly?" but "what is the evidence that restarting helps, and how much of it do I need?" This post is about answering that with the graphs you already have: what a restart genuinely resets, how to tell a leak from a plateau, what cadence the evidence supports, and how to run the restart so nobody loses work. The mechanics of building the schedule - the cron line, the task order, the delays - are in scheduled tasks worth having.

What a restart actually resets#

A restart throws away the process and starts a new one from the same files. That is the whole of it, and the list of things it fixes follows directly.

The middle of that table is where most of the honest benefit lives. The bottom is where people put restarts anyway, and it is why a schedule that "helps a bit" often turns out to be doing nothing except interrupting people. If your complaint is that the server is slow at peak and fine at 04:00, restarting at 05:00 addresses nothing - read why TPS drops and what to do instead.

Proving you need one: read the memory graph#

The panel draws memory, CPU and disk against the limits of the plan. That graph answers the question directly if you look at it over days rather than minutes.

Restart the server, then note the memory figure at four points and compare the shape:

Server A                        Server Bafter restart   1.9 GB          after restart   1.9 GB+1 hour         2.6 GB          +1 hour         2.4 GB+6 hours        3.1 GB          +24 hours       3.4 GB+24 hours       3.2 GB          +48 hours       4.6 GB+72 hours       3.2 GB          +72 hours       5.8 GB

Server A fills up and plateaus. That is not a leak, it is a cache doing its job, and a nightly restart buys you nothing except a nightly interruption. Server B's floor rises every day and will eventually reach the ceiling; that is a leak, and a restart is a legitimate stopgap until it is found.

The distinction to watch is the floor, not the peak. Peaks move with player count and mean little. A floor that is higher every morning than it was the previous morning is the signature. Reading a server load graph goes through the other shapes on the same chart.

For Minecraft, add a second measurement that is not memory: /mspt in Paper reports how long a tick takes, and its trend over days tells you whether the simulation is degrading rather than just the heap. If it rises steadily, a profile will find the cause in about ten minutes - reading a spark report covers that. For a Node or Python application the equivalent is watching resident memory against the limit, with the detail in Node memory limits explained.

A clean stop and a kill are not the same event#

This is the part that makes restarts either free or expensive, and it is invisible until the first time it costs you.

• Stop and Restart ask the server to shut down. The process gets the chance to save, flush its logs and close its files. For a game whose world lives in memory, that save is the entire point.
• Kill does not ask. The process disappears. Anything not written to disk is gone.
• An out-of-memory stop is closer to a kill. At the memory limit the container is stopped by the kernel and comes back clean rather than being left to swap, which keeps the machine healthy and other servers fast, but it is an unplanned stop from the game's point of view. Whatever the world had in memory at that instant is lost.

That last point is the strongest argument for a restart schedule on a server with a real leak. It is not about performance; it is about who chooses the moment. A restart at 05:00 with a save in front of it costs nothing. The same server reaching its ceiling at 21:30 costs everybody the last save interval, and Valheim's default is thirty minutes.

How often, and the evidence for each cadence#

Match the interval to what the graph showed, not to what other servers do.

The threshold to be honest about: if a server needs restarting more than once a day to stay usable, the restart is not the fix. Either the plan is too small for what is running on it, or something is broken. Why your game server keeps restarting separates the causes, and the answer is often that the memory limit and the configured heap are fighting each other.

Weekly is underrated. A large modded server that creeps gently can run seven days without trouble, and one interruption a week is far easier to schedule around a community's habits than seven.

Restarting without anybody losing anything#

The sequence matters more than the timing. A restart that arrives without warning during a boss fight costs you more goodwill than the memory it reclaimed.

1. Warn twice. Fifteen minutes and five minutes out, in game. Post the schedule in Discord once so it is not news every night.
2. Force a save before stopping. save-all flush for Minecraft, Save over RCON for Palworld, saveworld for 7 Days to Die. Games without a console command - Valheim among them - rely on the clean stop doing it, which is exactly why the restart must be a Stop and not a Kill.
3. Take the backup before the restart, not during it. A backup of a shutting-down server is a backup of a shutting-down server, and it is the archive you will reach for if the restart is the moment something breaks - backups that actually restore covers what has to be in it.
4. Leave a gap. Sixty seconds between the save and the stop, and between the stop and anything that follows.
5. Pick the quiet hour, and avoid 02:00 to 03:00, where summer time changes make a job run twice or not at all.

Then check the first restart by hand. Watch the console through the whole sequence once, confirm the save line appears before the stop line, and confirm the server comes back. Schedules fail silently, and the night you discover yours has been killing the server without saving for three weeks is a bad night. Reading the console covers what those lines look like.

What a nightly restart hides#

If the restart is load-bearing, something underneath it is broken. The list of usual suspects is short, and each has a way to confirm it.

• A leak in a mod or plugin. Add one suspect back at a time after a restart and watch the 24-hour floor. Tedious, effective, and there is no shortcut.
• Entity accumulation. Item frames, armour stands, minecarts and mob farms are stored in the world and survive restarts; what the restart clears is the dropped items and the loaded chunks around them. Count entities before blaming memory.
• Chunk loaders and always-loaded areas. A server where twenty chunk loaders keep distant machinery ticking pays for it every tick, not just after three days.
• Logs filling the disk. Restarts do not free disk. A server that behaves for a week and then misbehaves is often one that is simply running out of space - check disk on the same graph as memory. Logs worth keeping has the retention side.
• A database that has never been maintained. Table bloat and missing indexes get slowly worse and no restart of the game server touches them. For PostgreSQL that is vacuum and bloat; for anything else it is at least a look at the slow query log.
• Mods that were never compatible. A pack assembled from three versions will misbehave on a schedule of its own. Keeping a modded server clean is the prevention.

If a nightly restart is load-bearing, write down what it is hiding. That note is the actual bug report, and it is the only thing that ever turns the schedule off again.

Updates are restarts with a reason#

The other legitimate use of a restart is applying something. A game update, a mod update, a configuration change that is only read at start, a new Java version. These are not maintenance overhead; they are the point.

The rules are different from the nightly case, and they are worth separating:

• Back up first, and lock it. Not the nightly rotation - a deliberate backup taken immediately before the change, locked so it is not rotated out. If the update goes wrong, that archive is the way back, and testing a restore before you need it is how you know it works.
• Do not auto-update a modded server on patch day. Every game patch breaks mods until their authors catch up. Turn the update off, wait, then update deliberately - what to do when a mod update breaks.
• Announce it as an update, not a restart. People tolerate downtime they understand. "Updating to 1.21.4, back in fifteen minutes" is a different message from the server vanishing.
• For applications, a restart is a deploy. The same sequence, with health checks - see zero-downtime deploys on a small server.

When automatic restarts fight you#

There is a second source of restarts on any managed platform: the crash watcher. Ours polls every two minutes for a server that went offline or whose uptime went backwards, and brings it back. Restarts you asked for are not counted. Three unplanned restarts in an hour put a warning on the server page and open a ticket automatically; six suspends the server, which sounds harsh until you have watched a server crash-loop for a day.

That design has a practical consequence. A server that crashes on start will be restarted, crash, be restarted, and the counter climbs. The correct response is to stop it deliberately and read the last forty lines of the log before the crash, rather than letting the loop continue while you look for the cause. A stopped server is not an emergency; a looping one is noise that buries the line you need.

It also means your scheduled restarts are invisible to that counter, so a nightly schedule will never trip the warning. If you do see a three-in-an-hour warning, it is genuine: something is exiting on its own, and no schedule will fix it.

FAQ#

Do I need a nightly restart at all?

Only if the graph says so. Measure the memory floor over three days; if it plateaus, skip the schedule and check again after your next mod or plugin change. A weekly restart is a reasonable default for anything modded, and a plain vanilla server with a stable player count may genuinely need none.

What time should it run?

The quietest hour for your players, avoiding 02:00 to 03:00 because of summer time. For most European communities that is 04:00 to 06:00. Check your own peak times instead of copying a default - a server whose players are elsewhere has its quiet hour elsewhere too.

Will a restart fix lag?

Only lag caused by something accumulating in the process. Lag that appears when twenty people log in is a capacity or configuration problem and will be back within the hour. The quick test: if the server is fast at 04:00 and slow at 20:00, restarting at 05:00 changes nothing.

Does restarting lose progress?

A clean stop saves first, so no. A kill or an out-of-memory stop loses everything since the last save, which for some games is up to half an hour. Always use Stop or Restart, put a save command in front of it, and keep the game's own save interval short on a server that is close to its memory limit.

Should I restart before or after taking the backup?

Backup first, then restart. The archive should be of a settled, saved world, not of one in the middle of shutting down. The full ordering - warn, save, archive, restart - is in the schedule sequence covered in scheduled tasks worth having.

Can I restart only when memory is high, instead of on a timer?

Not with a cron schedule, which only knows the clock. In practice the timer is close enough: pick an interval shorter than the time it takes to reach the limit, and treat the need for a tighter one as the signal to fix the leak or move up a tier. Changing plan does not rebuild the server, so the memory limit can be raised on the server you already have.