---
title: "Minecraft Scheduled Restarts and Server Automation"
description: "Why a nightly Minecraft restart helps, how to build a warned restart and backup in the panel Schedules tab, and why a restart never fixes a real leak."
url: "https://www.gameserverkings.com/knowledge-base/minecraft/scheduled-restarts-and-automation/"
category: "Minecraft"
category_url: "https://www.gameserverkings.com/knowledge-base/minecraft/"
published: "2026-08-19T05:17:20.542Z"
updated: "2026-08-19T08:04:30.863Z"
source_format: "markdown"
site: "GameServerKings"
---

# Minecraft Scheduled Restarts and Server Automation

A Minecraft server that nobody touches for a week does not stay in the state you left it. Entities accumulate, plugins hold onto things they meant to release, the heap fills with objects the collector keeps having to walk past, and one morning the server that ran at 18 ms per tick is running at 45. A nightly restart resets all of that in thirty seconds, and it is the single highest-value piece of automation you can set up.

This guide covers what a restart actually fixes, what it very deliberately does not fix, and how to build the restart, the warnings and the backup as one schedule in the panel. Everything here is Java Edition on a panel-hosted server; the Schedules tab itself works identically for Bedrock.

> [!NOTE] Looking for something else?
> If your server is *already* slow and you want to know why, start with [Diagnosing Minecraft Server Lag](/knowledge-base/minecraft/diagnosing-lag-and-low-tps/) — a restart will hide the symptom and cost you the evidence. If you want the backup workflow itself rather than the automation around it, that is [Managing your Minecraft server](/knowledge-base/minecraft/performance-and-backups/).

## What a Restart Actually Does

A restart ends the Java process and starts a new one. Everything the old process was holding goes with it:

- **The heap.** Every object the server had allocated is gone, including anything a plugin was leaking. The new process starts from an empty heap and grows into it.
- **Loaded chunks and their entities.** Item frames, dropped items, minecarts, boats, stray mobs and every armour stand somebody left in a corner are unloaded, and only the ones the world file actually contains come back.
- **Plugin state.** Caches, scheduled tasks, open database handles, listener registrations, and whatever a badly-behaved plugin has pinned in memory.
- **Anything you changed on disk.** Most config files are read once, at startup. A restart is how they take effect.

That is the whole mechanism. It is a reset, not a repair — and the difference matters more than anything else on this page.

### Memory: what is real and what is not

The most common reason people schedule restarts is a memory graph that climbs all day. Usually that graph is telling you nothing.

Java claims heap from the operating system and does not hand it back. The panel's memory meter therefore rises during the first hour of uptime and then sits high forever, on a perfectly healthy server. PaperMC is blunt about it:

> *"Unless you're experiencing out of memory crashes or bad garbage collection (GC) times, high memory usage is expected."*
>
> *"This is not a memory leak and will not cause out of memory crashes, which are commonly caused by not leaving enough RAM for your OS or improperly configured memory limits in a container."*

So a meter at 90% is not a reason to restart. What *is* a reason:

| Symptom | What it means |
|---|---|
| Memory high and steady, ticks fine | Normal. Do nothing |
| GC pause times climbing over days | Real pressure. A restart buys time; sizing or a plugin is the fix |
| `java.lang.OutOfMemoryError` in `logs/latest.log` | Real. The heap genuinely ran out |
| The process vanishes with no crash report | The container hit its memory limit. Give the server less to hold, or move to a plan with more RAM |

The heap-sizing rules, Aikar's flags and the Java version requirement are all in [Minecraft Server RAM and JVM Flags](/knowledge-base/minecraft/allocating-ram-and-jvm-flags/). Note that a high meter is not something you can respond to with a flag here in any case: your server launches with `-XX:MaxRAMPercentage=95.0` and no `-Xmx`, so the heap is set from your plan's RAM and there is nothing on the **Startup** tab to raise or lower. Where memory pressure is genuinely real, the levers are reducing what the server holds — view and simulation distance, entity counts, plugins — or a larger plan.

### What genuinely accumulates

Two things really do build up over a long uptime and really are cleared by a restart.

**Entities.** Every mob farm, every dropped item that nobody picked up, every boat left at spawn. These are saved to the world, so a restart does not delete them — but it does unload the chunks they live in, which stops them ticking until a player comes back. If your server is slower on day three than on day one and `/spark tps` blames entities, the restart is treating a symptom that [Diagnosing Minecraft Server Lag](/knowledge-base/minecraft/diagnosing-lag-and-low-tps/) can treat properly.

**Plugin state.** This is the honest one. A plugin that registers a repeating task on every world load, or caches player data and never evicts it, gets slower the longer it runs. You will not fix that from your side. A nightly restart makes it invisible, which is a legitimate thing to do while you wait for the author to ship a fix.

> [!IMPORTANT] A restart is maintenance, not a diagnosis
> One restart a day is hygiene. Needing one every six hours to stay playable is a fault report. The interval you need is the measurement: write it down, then go and find what is degrading that fast. Restarting more often instead is how a server ends up on a four-hour cycle that everybody has stopped questioning.

## Why "Restart More Often" Is the Wrong Answer to a Leak

The reason this is worth spelling out is that restarting works *just well enough* to stop you looking. A real leak has a slope. If you restart every 24 hours it takes 24 hours to become a problem; halve the interval and it takes twelve. Nothing about the leak changed — you only moved the point at which players notice.

Before you shorten the interval, spend one cycle collecting evidence:

1. Restart, then note the MSPT and memory figures from `/spark tps` and `/spark health --memory`.
2. Take the same two readings every few hours through the day.
3. If MSPT climbs steadily while player count does not, you have something that grows with uptime rather than with load. That is a leak-shaped curve.
4. Run `spark profiler start --timeout 600` while the server is in its degraded state, not while it is fresh — the whole point is to catch the thing that grew.

[Diagnosing Minecraft Server Lag](/knowledge-base/minecraft/diagnosing-lag-and-low-tps/) covers reading those profiles and bisecting the plugin list. [Reading Minecraft Server Logs and Crash Reports](/knowledge-base/minecraft/reading-crash-logs-and-common-errors/) covers the watchdog dumps and `OutOfMemoryError` traces that sometimes name the culprit outright.

## What the Panel's Restart Actually Does to Your Server

Worth knowing before you automate it, because it explains several of the failure modes below.

A **Restart** power action from the panel is a stop followed by a start. The daemon issues the stop, then waits for the process to exit — up to **ten minutes** — and only if it has not exited by then does it kill the container outright with `SIGKILL`. Then it starts it again.

The stop itself is not a kill. For a Minecraft Java server, the daemon sends the console command `stop`, and vanilla's `/stop` is defined as: *"Stops a server. Saves all changes to disk, then shuts down the server. Additionally, all players are kicked out of the server."* A panel restart is therefore a clean, saving shutdown. Nothing is lost by it.

> [!WARNING] Use a power action, not a `stop` command, in your schedule
> The daemon watches for the server going offline and treats an unexpected exit as a crash — which, with the defaults, means it starts the server again by itself. It only knows a shutdown was intentional if the command it sees matches the configured stop command **exactly**. Typing `stop` matches; `/stop` with a slash, or `stop ` with a trailing space, does not, and the daemon will bring the server back up as a "crash recovery". Either way you have no control over the restart, so use a **Send power action → Restart** task and let the panel own the sequence.

Crash recovery has one more behaviour worth knowing: it refuses to restart a server that crashed **less than 60 seconds** after the previous crash, and prints `Aborting automatic restart, last crash occurred less than 60 seconds ago.` to the console. That guard exists to stop boot loops. If your server keeps dying at startup and then stops trying, that message is why — the fault is in the startup, and [Reading Minecraft Server Logs and Crash Reports](/knowledge-base/minecraft/reading-crash-logs-and-common-errors/) is where to take it.

## Building the Restart Schedule

The panel's **Schedules** tab is a cron timer with a list of tasks attached. The tab-by-tab walkthrough — creating a schedule, the cron fields, the three task types — is in [How to Setup Schedules](/knowledge-base/general/how-to-setup-schedules/). What follows is the Minecraft-specific shape.

A schedule has five cron fields (minute, hour, day of month, month, day of week) and each defaults to `*`, meaning every. The scheduler checks for due schedules **once a minute**, so a schedule is accurate to the minute and no finer.

| Goal | Minute | Hour | Day of Month | Month | Day of Week |
|---|---|---|---|---|---|
| Every day at 4 AM | `0` | `4` | `*` | `*` | `*` |
| Every 6 hours | `0` | `*/6` | `*` | `*` | `*` |
| Sundays at 5 AM | `0` | `5` | `*` | `*` | `0` |
| First of the month | `0` | `6` | `1` | `*` | `*` |

### The warned restart

Each task is one of three actions — **send a command**, **send a power action**, or **create a backup** — and each carries a delay measured from the task before it. That is what turns a blunt restart into a polite one:

| # | Action | Payload | Delay |
|---|---|---|---|
| 1 | Send command | `say Server restarting in 5 minutes.` | 0s |
| 2 | Send command | `say Server restarting in 1 minute.` | 240s |
| 3 | Send command | `say Restarting now — back in about a minute.` | 55s |
| 4 | Send power action | Restart | 5s |

`/say` broadcasts as the server and needs permission level 2; the console runs above that, so a schedule can always send it. Set the schedule's cron to `0 4 * * *` and the first warning fires at 04:00, the restart at 04:05.

![A restart schedule in the panel: cron fields, a warning command, then a delayed power action](<https://cdn.gskinternal.com/articles/images/minecraft-schedule-restart.png>)

> [!IMPORTANT] 900 seconds is the hard ceiling on a single delay
> Each task's delay is capped at **900 seconds — fifteen minutes**. There is no way to ask for a longer one. A thirty-minute warning window has to be built as two or more chained tasks, each under the cap. This is the limit people hit when they try to give players an hour's notice from a single task and quietly get a validation error instead.

Two more properties of the delay that catch people out:

- **The delay on the *first* task delays the whole run.** It is not ignored — despite the panel's own help text under the field, which says that on a first task the offset "will not be applied". That hint is only true of a manual run. On the timer, a first task with a 300-second offset means the schedule fires at 04:00 and the first thing happens at 04:05.
- **Delays are cumulative, not absolute.** In the table above the restart happens at 0 + 240 + 55 + 5 = 300 seconds. If you want a task at a specific clock time, add the offsets up yourself; there is no field for "at 04:05".

### The "only when server is online" toggle

With this on, the panel checks the server's state before running anything and skips the entire schedule if the server is **offline or stopping**. Use it on restart and backup schedules so a server you deliberately stopped does not get started again at 4 AM by a power action.

Note the wording: it skips the *whole run*, not just the power task. That is usually what you want, and it is occasionally surprising — a schedule that both announces something and restarts will do neither.

## Backups and Restarts Together

The two jobs interact, and the order is worth getting right.

**Back up before the restart, not after.** A backup is insurance against the state you are about to leave behind. Taking it after the restart means that if the restart is the thing that goes wrong — a config you edited that the server now refuses to load — your most recent snapshot is of the broken server.

**Flush the world first.** A backup copies files. The server writes chunks lazily: `ticks-per.autosave` in `bukkit.yml` defaults to **6000 ticks**, which is five minutes at a healthy 20 TPS, so up to five minutes of block changes can be sitting in memory when the copy starts. Running `save-all flush` first — *"All the players and chunks are saved to the data storage device immediately, freezing the server for a short time"* — closes that window.

A combined schedule at `0 4 * * *`:

| # | Action | Payload | Delay |
|---|---|---|---|
| 1 | Send command | `say Nightly maintenance in 5 minutes.` | 0s |
| 2 | Send command | `say Nightly maintenance in 1 minute.` | 240s |
| 3 | Send command | `save-all flush` | 55s |
| 4 | Create backup | *(leave **Ignored Files** empty)* | 15s |
| 5 | Send power action | Restart | 300s |

Left empty, the **Ignored Files** box does not mean "ignore nothing" — the daemon falls back to the server's `.pteroignore` file, and only ignores nothing if that file is absent too.

> [!CAUTION] Do not put `save-off` in a schedule
> `save-off` stops the server writing to the level files — the wiki's words are *"All level changes are temporarily queued"* — and it stays off until a `save-on` clears it or the server restarts, because *"this option is reset each time the server restarts."* If a scheduled `save-off` ever runs without its matching `save-on` — because a later task failed, or because you edited the schedule and dropped a task — the world runs unsaved until the next restart, and a crash inside that window loses everything since. Panel backups do not need it. If you are pulling files by hand over SFTP, do it manually and watch it, as described in [Managing your Minecraft server](/knowledge-base/minecraft/performance-and-backups/).

The five-minute gap between the backup and the restart in the table above is a guess, and it is the weakest part of the design: the schedule does not wait for the backup to finish, it just starts the next timer. A large Minecraft world can take ten to thirty minutes to back up. The restart will interrupt it.

> [!TIP] Give the backup its own schedule
> The robust arrangement is two schedules: a backup at `0 3 * * *` and a restart at `0 4 * * *`. An hour apart, they cannot collide, neither has to guess how long the other takes, and if you later want the backup twice a day you change one schedule instead of untangling a chain. Retention still applies — the standard allowance is five backups per server, and a schedule that hits the limit with everything locked fails quietly every night. [How to Create a Backup](/knowledge-base/general/how-to-create-a-backup/) covers the allowance and the locking trap.

## Other Jobs Worth Automating

Once you have the pattern, most routine admin work fits it.

| Job | Task | Suggested cron |
|---|---|---|
| Trim the CoreProtect log | Send command: `co purge t:30d` | `0 6 * * 0` (Sundays) |
| Reload the whitelist after bulk edits | Send command: `whitelist reload` | Run manually, not on a timer |
| Force a save before a busy period | Send command: `save-all flush` | `0 18 * * *` |
| Weekly deep restart plus backup | Backup + Restart chain | `0 5 * * 1` |
| Announce a scheduled event | Send command: `say …` | Whatever the event is |

A few notes on those:

- **`co purge` is the one with teeth.** CoreProtect's rollback window *is* whatever retention you purge at, so putting `co purge t:30d` on a weekly schedule silently commits you to a 30-day investigation window. Read the retention section of [Minecraft Grief Protection and Rollback](/knowledge-base/minecraft/grief-protection-and-rollback/) before you set the number, not after.
- **`whitelist reload` is a manual job, not a scheduled one.** It exists to pick up hand edits to `whitelist.json`, and running it on a timer with `enforce-whitelist=true` means players get kicked at unpredictable moments. See [Minecraft Whitelist and Ban Management](/knowledge-base/minecraft/whitelist-and-ban-management/).
- **Anything that needs to run *while* the server is stopped** cannot be a schedule. Schedules send commands to a running server or press power buttons; they cannot edit files. Version upgrades in particular are a hands-on job — see [Updating Your Minecraft Server](/knowledge-base/minecraft/updating-your-server-version/).

## When a Schedule Silently Stops Working

Schedules fail quietly by design — nothing emails you. Four causes account for nearly all of it.

**A task failed and took the rest of the chain with it.** If a task errors, the run stops there. The tasks after it, including your restart, never happen. Each task has a **continue on failure** option, off by default; turning it on lets the chain survive a task that failed because the daemon was briefly unreachable. It does not rescue every kind of failure — a task rejected for another reason still ends the run.

**The server was offline or stopping.** With "only when server is online" enabled, the whole run is skipped. That is the setting doing its job, but it means a server that crashed at 2 AM also misses its 4 AM backup.

**The previous run had not finished.** A schedule is skipped while it is still marked as processing. Chain enough 900-second delays together and a schedule can overrun its own interval, at which point the next occurrence is skipped rather than stacked. Keep total chain length comfortably under the gap between runs.

> [!WARNING] A schedule stuck on "processing" never fires again
> That flag is set before the first task runs and cleared when the last one finishes. If the run never starts — most often because the panel's queue worker is not running — nothing ever clears it, and the schedule silently stops firing while still looking perfectly configured in the UI. There is no timeout. The reset is to toggle the schedule **off and back on**, which clears the flag; if it happens repeatedly, the queue worker is the thing to fix, so open a ticket rather than rebuilding the schedule.

**The cron fields are wrong.** The classic is putting the hour in the minute field: `4 0 * * *` is 00:04, not 04:00. The panel shows a next-run time once the schedule is saved — read it, and if it does not say what you expected, fix the fields rather than waiting a day to find out.

> [!TIP] Test with the run-now button before trusting the timer
> Every schedule can be triggered by hand. Run it once with the server up and watch the console: you will see each `say` land and the restart happen, in order, with the real delays — the first task's own offset is skipped on a manual run, but every offset after it is honoured. Five minutes of watching beats a week of assuming.

## Common Issues

- **The restart happens but nobody was warned.** The warning tasks are after the power action in the sequence, or their delays add up past it. Delays are cumulative from the previous task — add them yourself.
- **The server restarts twice.** You have both a `stop` command task and a Restart power action, or a `stop` task whose text does not match the configured stop command, so crash recovery started it and then your power action restarted it again.
- **The server came back up after you stopped it.** Crash recovery. Stop it from the panel's Stop button rather than by console command, and check whether a schedule with a power action ran.
- **The schedule ran but the backup is missing.** Check the **Backups** tab for the allowance message. At the limit with every backup locked, new ones fail — silently, every night. See [How to Create a Backup](/knowledge-base/general/how-to-create-a-backup/).
- **`Aborting automatic restart, last crash occurred less than 60 seconds ago.`** The server is failing during startup, not during play. Read `logs/latest.log` from the top; [Reading Minecraft Server Logs and Crash Reports](/knowledge-base/minecraft/reading-crash-logs-and-common-errors/) decodes the usual startup errors.
- **The restart takes several minutes.** A large world takes time to save on shutdown. That is `stop` doing its job. Only if the process has not exited after ten minutes does the daemon kill it, and a server that regularly needs that long has a save problem worth profiling.
- **A schedule fired an hour off.** Cron fields are evaluated against the panel's clock, not your local time zone. Set the times relative to what the panel's next-run display shows you.

## FAQ

### How often should I restart a Minecraft server?

Once a day, during your quietest hour, is right for almost every server. It clears accumulated entity and plugin state at a moment nobody is playing. If you find you need more than that to stay playable, the interval is a symptom — go and diagnose it rather than shortening it.

### Does a scheduled restart lose anything?

No. A panel restart sends the server's stop command, and `/stop` saves all changes to disk before shutting down. Players are disconnected and reconnect a minute later with everything intact. Adding a `save-all flush` before the restart is belt-and-braces, not a requirement.

### Will restarting fix my lag?

Temporarily, and only if the lag grows with uptime. If the server is slow within minutes of starting, a restart changes nothing — that is a load or configuration problem, and [Diagnosing Minecraft Server Lag](/knowledge-base/minecraft/diagnosing-lag-and-low-tps/) is the guide for it.

### How do I warn players before a restart?

Chain `say` commands ahead of the power action, with delays between them. Five minutes, one minute and "now" is the pattern players are used to. Each delay is capped at 900 seconds, so long warning windows need more than one task.

### Can I schedule something more often than once a minute?

No. The scheduler checks for due schedules once a minute, so that is the finest granularity available. Sub-minute timing has to come from a plugin running inside the server.

### Should the backup run before or after the restart?

Before. The backup is insurance against the change you are about to make, and a restart is a change. Give it its own schedule an hour earlier so the two cannot overlap.

### Why did my server start itself back up?

Crash recovery. The daemon restarts a server that goes offline unexpectedly, and it treats a clean exit as unexpected unless it recognises the command that caused it. Use the panel's Stop button, or a Send power action task, rather than typing a stop command.

### Do I need a plugin to schedule restarts?

No. The panel's Schedules tab does everything described here, and it works even when the Minecraft server itself is unresponsive — which is exactly when a plugin-based scheduler would not. Plugins are worth adding for in-world niceties like on-screen countdowns and boss-bar timers, not for the restart itself.

## What to Read Next

- [How to Setup Schedules](/knowledge-base/general/how-to-setup-schedules/) for the panel tab itself: creating a schedule, the cron fields and the three task types
- [Managing your Minecraft server](/knowledge-base/minecraft/performance-and-backups/) for the backup routine, save commands and what a Minecraft world actually contains
- [Diagnosing Minecraft Server Lag](/knowledge-base/minecraft/diagnosing-lag-and-low-tps/) for finding out what you are restarting away from
- [Minecraft Server RAM and JVM Flags](/knowledge-base/minecraft/allocating-ram-and-jvm-flags/) for heap sizing and why a high memory meter is not a leak
- [Reading Minecraft Server Logs and Crash Reports](/knowledge-base/minecraft/reading-crash-logs-and-common-errors/) for watchdog dumps, startup failures and boot loops
- [How to Create a Backup](/knowledge-base/general/how-to-create-a-backup/) for the backup allowance, locking and restores
- [Minecraft Grief Protection and Rollback](/knowledge-base/minecraft/grief-protection-and-rollback/) for CoreProtect retention before you schedule a purge
- [Minecraft Anti-Cheat and Fair Play](/knowledge-base/minecraft/anti-cheat-and-fair-play/) for the anti-xray settings that need a restart to take effect

---

Made with 💜 by GameServerKings