How to Schedule Automatic Restarts on a Minecraft Server

To schedule automatic restarts you set up two cooperating pieces: something that stops the server on a schedule, and something that brings it back up after the JVM exits. Once those two halves are in place you pick the trigger that fits your stack — a restart loop in the start script (or a systemd service), a cron job, or a scheduler plugin that gives players a countdown before it pulls the plug.

The reason to bother is simple. A once-a-day restart clears the memory leaks that pile up over long uptime, hands RAM back to a clean baseline, and keeps TPS from sagging the longer the box has been running. So the job here is to choose a trigger, point it at your quietest hour, and pair it with a backup. None of this is version-specific, either — restart mechanics didn't change between the 26.1 and 26.2 drops, so the same setup carries across both.

Why a daily restart keeps a server healthy

A JVM that has been up for days slowly fills with cruft. Plugins and mods hold onto references they never release, the heap fragments, and the set of loaded chunks and entities keeps growing. RAM creeps toward the -Xmx ceiling, garbage-collection pauses get longer and land more often, and TPS drifts down while spikes show up more frequently. You usually feel it as a server that ran great on Monday and feels sluggish by Thursday with the same player count.

A restart wipes most of that. It drops the leaked references, clears the heap back to a clean baseline, frees the RAM that crept up, and resets the garbage collector. It also applies anything you queued that only takes effect on a fresh boot — a new plugin jar, a config edit, a server-software update.

What a restart won't do is fix a real leak. If RAM maxes out within a few hours of a clean boot, you have a leak to trace, not a cadence to tighten. That's a job for the same tools you'd use on any slowdown: read the numbers behind TPS lag spikes, work through reducing RAM usage, and put Aikar's JVM flags on the launch line so the garbage collector behaves and each uptime window stays smooth for longer. A restart is hygiene that buys you time; flags and profiling are what actually stretch the window.

The two halves of every automatic restart

Every method needs two things: a trigger that stops the server at the scheduled time, and a relauncher that starts a new JVM once the old one has exited. A plugin or a cron job can stop the server, but nothing comes back on its own — a loop, a service, or a restart script has to relaunch the process.

This is also the single most common confusion, so name it now: "my plugin restarted the server but it stayed down" almost always means the plugin ran /stop or /restart and there was no relauncher behind it. Seen that way, the three options below aren't rivals — they're pieces you combine.

One rule sits on top of both halves: always stop gracefully with /stop. A clean stop saves the world, flushes everything to disk, and releases session.lock. Never schedule a kill -9 or any hard process kill — that, not the restart itself, is what corrupts a world, because you're yanking the process mid-write.

Option 1: A restart loop in the start script

This is the relauncher half. You run the jar inside a shell loop so that whenever the server exits, the loop launches a fresh one:

while true; do
  java -Xms4G -Xmx4G -jar server.jar nogui
  echo "Server stopped. Restarting in 5 seconds..."
  sleep 5
done

Run that inside a screen or tmux session so the console stays attachable. When the server goes down through /stop, /restart, or a crash, the loop spins up a new JVM. On its own, though, the loop schedules nothing — it only reacts to the server exiting. You still need a trigger to stop it on a clock, which is where Option 2 or Option 3 comes in.

On a modern Linux box, a systemd service is the cleaner version of that bash loop. A unit with Restart=always does the same job, survives a host reboot, and logs to the journal instead of a detached screen. Pair it with a systemd timer and the timer becomes your scheduled trigger, all inside one tool.

Paper and Spigot also ship a built-in route. Set settings.restart-script in spigot.yml (it defaults to ./start.sh) and turn on restart-on-crash: true; the /restart command and the crash handler will both spawn that script. One caveat to plan around: the restart script launches the new process before the old one has fully released the port, so on a tight box you can hit "Unable to bind" or a port-in-use error. Run it under screen and leave some RAM and CPU headroom and it behaves. If you're turning on restart-on-crash, dig into why a server keeps crashing first, since an auto-restart on a crash loop just hides the cause.

Option 2: A cron job on Linux

cron is the trigger half. You schedule a job that warns players, flushes the world, and stops the server, and your loop or systemd service from Option 1 brings it back. There are two common ways to push commands into a running server: screen's stuff command, which types into the session, or RCON through a tool like mcrcon. RCON needs enable-rcon=true, plus rcon.port and rcon.password, set in server.properties.

The mcrcon pattern looks like this:

mcrcon -H localhost -P 25575 -p yourpassword -w 5 \
  "say Restarting in 5 seconds" save-all stop

The -w 5 waits five seconds between commands, so the warning actually reaches players and the save finishes before the stop fires. Drop that into a crontab line:

0 5 * * * /home/mc/restart.sh

That runs at 05:00 every day. One thing that catches people: cron uses the server box's local timezone, so set the box to your playerbase's timezone rather than leaving it on UTC and bouncing the server at what turns out to be peak for your players.

The strengths here are that there's no plugin to maintain, it's OS-level reliable, and the same script can kick off a backup right before the stop.

Option 3: A scheduler plugin with countdown warnings

If you'd rather keep everything inside the server, a scheduler plugin handles the trigger for you. AutoRestart, DailyAutoRestart, SimpleAutoRestart, RestartAnnouncer and similar plugins fire at set wall-clock times or fixed intervals and give graduated countdown warnings — typical defaults are notices at 60, 30, 15, 5, and 1 minute, then a 10-second count — surfaced through chat, a title, the action bar, or a boss bar. Many support MiniMessage or legacy formatting so you can style the warning text.

This is the best player experience of the three, and the warnings are the entire point: nobody gets yanked out of a fight or a half-finished build without warning. If you care about how the restart feels from a player's seat, this is the option to reach for.

It does not get you out of the two-halves rule, though. The plugin is still only a trigger — it calls /stop or /restart and cannot relaunch the JVM by itself. It has to run on top of a start-script loop, a systemd Restart=always service, or a spigot.yml restart-script, or the server just stays down after the first scheduled restart. Treat any config keys you read in a guide as examples and check the plugin's own docs, since command and option names drift between releases.

Timing: restart during your quietest hours

Point the restart at your lowest-traffic window, and read your actual player-activity pattern to find it rather than guessing. For most servers that's pre-dawn in the core playerbase's timezone, somewhere around 4 to 6 AM. Keep it well clear of peak hours; a restart that lands on a full server throws away whatever session everyone was in the middle of.

One restart a day is enough for most servers. A heavy modpack or a known-leaky setup can justify every 12 or every 6 hours, but let the RAM and TPS trend across an uptime window make that call instead of picking a number. And if you need a restart every couple of hours just to stay playable, that points back at a leak — and no schedule fixes a leak.

Warn players even at 5 AM, because there are always a few stragglers and AFK accounts sitting in a base, and the countdown gives them time to reach somewhere safe before the world unloads. If you run a network, stagger the restarts off round numbers so the whole stack doesn't bounce in the same second and leave every player staring at a connection error at once.

Pair the restart with a backup

A scheduled restart is a tidy checkpoint to snapshot the world, and it drops into the same off-hours window you already picked. For the full routine, lean on how to back up a Minecraft server. Because a clean /stop has already flushed everything to disk, the moment the server is fully stopped the world folders are quiet and safe to copy — or you can use the save-off, save-all flush, save-on dance to grab a copy just before the stop on a box that can't afford the downtime.

Sequencing is the thing to get right. Order the backup so it finishes before the relauncher grabs the files, or take the copy while the server is stopped — don't fire a heavy backup flush and the restart's own save in the same instant, because you'll stack two freezes on top of each other. Keep both jobs in the same low-traffic window, but run them one after the other rather than both at once.

FAQ

Can I just use /reload instead of a full restart?

No. /reload re-reads some configuration but doesn't clear the heap, free leaked memory, or reset garbage collection, and it's well known for leaving plugins in a broken, half-loaded state. The memory hygiene that keeps TPS healthy across long uptime only comes from a full process restart, which /reload doesn't give you.

How long will players be down during a restart?

Not long, but it isn't instant. The graceful /stop takes a few seconds to save and shut down, and then the new JVM has to load the world and start plugins before it accepts connections — figure roughly 15 to 60 seconds on a modest server, longer on a heavy modpack with a lot of plugins. Players get a connection error the moment the old process goes down and can reconnect once the new one is up, so the countdown warning earns its keep: it tells them the gap is coming instead of leaving them wondering whether the server crashed.

I'm on managed hosting with no shell access — can I still schedule restarts?

Yes. Most game-host control panels — Pterodactyl, Multicraft and the like — have a scheduler or task tab built in, where you set a time and an action (usually a power restart or a console command) without touching cron or a start script. The panel itself plays the relauncher role, so you don't have to wire one up. If your host only exposes a console and no scheduler, a scheduler plugin from Option 3 is the fallback, since it runs inside the server and the panel's own keep-alive brings the process back.