Automating Your Game Server: Schedules, Backups, and Restarts

Running a game server shouldn’t mean waking up at 3 AM to restart it because performance tanked overnight. It shouldn’t mean realizing your last backup was two weeks ago right after a griefer wiped your spawn. And it definitely shouldn’t mean manually typing save-all every few hours because you don’t trust the auto-save interval.

Automation handles the routine so you can focus on what actually matters — building your community, planning events, and playing the game yourself once in a while.

This guide covers the practical automation tools available through the Witchly dashboard, from simple scheduled restarts to advanced task chains that handle entire maintenance routines without you lifting a finger.

Why Automation Matters

Game servers degrade over time. This isn’t a flaw in your setup — it’s the nature of long-running processes, especially for Java-based games like Minecraft.

Here’s what happens when a server runs for days without intervention:

• Memory leaks accumulate. Plugins and mods allocate memory that never gets fully reclaimed. Java’s garbage collector does its best, but fragmentation builds up. A server that starts using 2 GB of RAM will be consuming 5 GB after three days of continuous operation.
• Entities pile up. Dropped items, mobs stuck in caves, minecarts nobody’s using, armor stands from abandoned builds. Every entity consumes CPU cycles every single tick. A server with 3,000 loaded entities performs noticeably worse than one with 800.
• Worlds grow and need protection. Every hour of gameplay adds chunks, builds, and progress that exists only on disk. One corrupted file, one bad plugin update, one accidental rm -rf — and it’s gone. Unless you have backups.
• Plugin and mod state gets stale. Some plugins cache data in memory, maintain connection pools, or accumulate log buffers. A clean restart resets all of this to a known good state.

Manual management works when you have one server and plenty of free time. It falls apart the moment you have responsibilities outside of server administration. Automation turns reactive firefighting into proactive maintenance.

Scheduled Restarts

If you automate only one thing, make it this. Scheduled restarts are the single most impactful automation for game server health.

Why Servers Need Periodic Restarts

Java’s garbage collector is good, but it’s not perfect. Over time, the heap becomes fragmented — large contiguous memory blocks get broken into smaller pieces that can’t be efficiently reused. The GC spends increasingly more time trying to clean up, stealing CPU cycles from your actual game logic.

Plugins compound the problem. Most Minecraft plugins, for example, are written by hobbyist developers. Memory leaks are common. A plugin that leaks 50 MB per hour doesn’t sound like much, but after 48 hours that’s 2.4 GB of wasted RAM.

Entity accumulation is another factor. Even with despawn timers, entities build up in loaded chunks — especially on servers with keep-inventory enabled, where dropped items from deaths don’t exist but other item sources continue generating.

A daily restart clears all of this. Memory resets to baseline, entities despawn cleanly, plugin state reinitializes, and the garbage collector starts fresh with a clean heap.

Setting Up Auto-Restart

Through the Witchly dashboard, scheduled restarts are straightforward:

1. Navigate to your server’s Schedules tab.
2. Create a new schedule and set the timing (more on cron expressions later).
3. Add a Restart Server task.
4. Enable the schedule.

For most servers, a single daily restart during your lowest-activity window works well. If your server is in a North American timezone with most players online in the evening, a restart at 4:00 AM local time means minimal disruption.

High-population servers or heavily modded servers may benefit from more frequent restarts — every 6 or 12 hours. If you notice TPS degradation within hours of a restart, that’s a sign you need shorter intervals (or that a specific plugin needs investigating).

Warning Players Before Restart

A sudden restart is jarring. Players lose unsaved progress, get disconnected mid-fight, or assume the server crashed. Always warn before restarting.

The best approach is task chaining (covered in detail below), but here’s the basic idea:

• Task 1: Send a warning via console command — say Server restarting in 5 minutes. Save your progress!
• Task 2 (5 minutes later): Send a final warning — say Restarting now...
• Task 3 (10 seconds later): Restart the server.

Players see the warnings in chat, have time to find a safe spot, and know the restart is intentional. This small courtesy makes a big difference in how your community perceives server stability.

Automated Backups

You will forget to make manual backups. Everyone does. And the one time you desperately need a backup — after a world corruption, a bad plugin update, or a griefer with operator access — will be the one time your most recent backup is from last month.

Automated backups eliminate this entirely.

Scheduling Backups

Set up a recurring backup schedule through the dashboard:

1. Go to your server’s Schedules tab.
2. Create a new schedule with your preferred frequency.
3. Add a Create Backup task.
4. Enable the schedule.

Daily backups are the recommended minimum. If your server has active builders or a large player base making significant changes every day, twice-daily backups provide better coverage. Weekly backups are acceptable only for servers with very low activity.

The best time to schedule a backup is right after a scheduled restart — the server is in a clean state, all chunks have been saved properly, and there’s no risk of backing up partially-written data.

Backup Retention and Management

Backups take up disk space, and your allocation isn’t infinite. The dashboard handles retention automatically — older backups are removed as new ones are created, based on your server’s backup slot limit.

But not all backups are equal. Some you want to keep permanently:

• Before major updates. Upgrading your Minecraft version, switching modpacks, or adding a major plugin? Lock that backup first.
• After significant milestones. Your community just finished a massive build project or completed a server event? Lock it.
• Known-good states. If your server is running perfectly — no lag, no bugs, no complaints — lock a backup. That’s your golden rollback point.

Locking a backup prevents it from being automatically deleted when retention limits are reached. You can lock and unlock backups from the backup management panel at any time.

Restore Options

When you need to restore from a backup, the dashboard gives you two options:

• Keep existing files: Restores the backup contents but preserves any files that exist on the server but weren’t in the backup. Useful when you only want to roll back specific data.
• Replace all files: Wipes the current server files and replaces them entirely with the backup contents. This is the nuclear option — use it when you want a complete rollback to the exact state captured in the backup.

Offsite Storage

Your server backups live on the same infrastructure as your server. For truly critical data, download backups to your local machine or a cloud storage service. The dashboard lets you download any backup directly. Even keeping one copy per week on Google Drive or Dropbox gives you an extra safety net against worst-case scenarios.

Task Chaining

This is where automation gets powerful. Instead of single actions, you can chain multiple tasks together in a sequence, each with its own timing offset.

How It Works

A schedule can contain multiple tasks, each executed in order. You control the delay between tasks using time offsets. The first task runs at the scheduled time, and each subsequent task runs after its specified delay from the previous one.

Example: Graceful Restart Sequence

Here’s a real-world schedule that handles a full restart cycle:

Order	Action	Delay	Command / Action
1	Send Command	0 min	say Server restart in 5 minutes — save your progress!
2	Send Command	5 min	say Restarting now...
3	Restart Server	10 sec	—

Players get a clear warning, have time to prepare, and the restart happens cleanly.

Example: Backup-Then-Restart

An even better approach combines backups with restarts:

Order	Action	Delay	Command / Action
1	Create Backup	0 min	—
2	Send Command	5 min	say Server restarting in 1 minute.
3	Restart Server	1 min	—

The backup captures the current state, then the server restarts cleanly. If the restart somehow causes an issue, you have a backup from moments before.

Continue on Failure

Each task in a chain has a continue on failure option. When enabled, the chain keeps executing even if that particular task fails. When disabled, a failure stops the entire chain.

For the backup-then-restart example, you probably want continue-on-failure disabled. If the backup fails, you don’t want to restart without that safety net. For a warning-message-then-restart chain, you probably want it enabled — a failed chat message shouldn’t prevent the restart.

Think carefully about which tasks are critical gates and which are nice-to-have.

Console Command Scheduling

Beyond restarts and backups, you can schedule any console command to run automatically. This opens up a wide range of maintenance and quality-of-life automation.

Automatic World Saves

While most server software auto-saves periodically, you can enforce additional save points:

• save-all (Minecraft) — forces an immediate world save to disk.

Schedule this 5-10 minutes before your backup task to ensure the backup captures the most recent state.

Periodic Announcements

Keep your community informed without repeating yourself:

• say Join our Discord for updates and events: discord.witchly.host
• say Server rules: No griefing, no cheating, be respectful.
• say Need help? Check our docs at witchly.host/docs

Schedule these every few hours. New players who missed the welcome message get the information they need. Just don’t overdo it — one announcement every 2-3 hours is plenty. More than that becomes spam.

Entity and Item Cleanup

For games that support it, scheduled cleanup commands prevent entity buildup:

• kill @e[type=item] (Minecraft) — removes all dropped items.
• kill @e[type=arrow] (Minecraft) — removes all arrows stuck in the world.

Schedule these every 30-60 minutes on busy servers. Pair them with a warning message so players aren’t surprised when their dropped items vanish.

Game Mode Specific Commands

Servers running specific game modes can automate environment control:

• time set day — keep it permanently daytime for building servers.
• weather clear — prevent weather effects on creative servers.
• difficulty normal — reset difficulty if a player changes it.

Cron Expressions Explained

Every schedule runs on a cron expression — a compact way to define recurring times. If you’ve never seen one before, they look cryptic. They’re actually straightforward once you understand the five fields.

The Five Fields

A cron expression has five fields separated by spaces:

┌───────── minute (0-59)
│ ┌─────── hour (0-23)
│ │ ┌───── day of month (1-31)
│ │ │ ┌─── month (1-12)
│ │ │ │ ┌─ day of week (0-6, Sunday = 0)
│ │ │ │ │
* * * * *

An asterisk (*) means “every.” A number means “at exactly this value.” A slash (*/n) means “every n intervals.”

Common Presets

You don’t need to memorize the syntax. Here are the expressions you’ll actually use:

Expression	Meaning
0 * * * *	Every hour, on the hour
*/30 * * * *	Every 30 minutes
0 */6 * * *	Every 6 hours (midnight, 6 AM, noon, 6 PM)
0 */12 * * *	Every 12 hours (midnight, noon)
0 4 * * *	Daily at 4:00 AM
0 4 * * 0	Weekly on Sunday at 4:00 AM
30 3 * * *	Daily at 3:30 AM
0 4 * * 1,4	Monday and Thursday at 4:00 AM

Reading a Cron Expression

Read right-to-left for the time scope, then left-to-right for the specifics:

• 0 4 * * * — Every day of every week, every month, at hour 4, minute 0. Daily at 4:00 AM.
• 0 */6 * * * — Every day, every 6 hours, at minute 0. Four times daily: midnight, 6 AM, noon, 6 PM.
• 0 4 * * 0 — Day of week 0 (Sunday), every month, at hour 4, minute 0. Weekly on Sunday at 4 AM.

The dashboard provides a human-readable preview of your cron expression, so you can verify it means what you think it means before saving.

Monitoring After Automation

Setting up automation and walking away forever is a mistake. Automation handles the routine, but you still need to verify it’s working.

Check Schedule Execution

The dashboard shows the last run time and next run time for every schedule. Glance at these periodically. If a schedule’s last run time is days ago when it should be running daily, something is wrong — the schedule might be disabled, or a task is failing and blocking the chain.

Review Resource Usage

After setting up scheduled restarts, check your server’s resource graphs over the following week. You should see a clear sawtooth pattern — memory and CPU usage climbing gradually, then dropping sharply at each restart.

If the pattern is:

• Clean sawtooth: Restarts are working as intended.
• Sawtooth but still peaking high: You might need more frequent restarts or need to investigate a memory-hungry plugin.
• Flat line near the limit: Restarts aren’t helping. The base memory usage is too high — you need to optimize your server configuration or reduce plugin load.

Monitor Backup Sizes

Backup sizes should grow slowly and predictably as your world expands. Watch for sudden changes:

• A sharp increase might mean a plugin is dumping large log files or a player explored a massive area quickly.
• A sharp decrease might indicate world corruption or missing files.
• Consistent growth is normal and expected.

Best Practices

After helping thousands of server owners set up automation, here’s what works:

Restart before backup, or backup before restart — pick a strategy and stick with it. Restarting first gives you a backup of a clean server state. Backing up first gives you a safety net in case the restart causes issues. Both approaches are valid. The backup-then-restart approach is slightly safer for most use cases.

Stagger multiple servers’ restart times. If you run three servers, don’t restart them all at 4:00 AM. Stagger them — 4:00, 4:15, and 4:30. This spreads the resource load and means your entire network isn’t offline simultaneously.

Test automation on a quiet day. Set up your schedules when the server is low-population. Watch the first few executions manually to confirm everything works. It’s much easier to fix a misconfigured schedule when five players are affected versus fifty.

Keep at least one locked backup at all times. Automatic retention will delete old backups to make room for new ones. If all your backups are unlocked and something goes catastrophically wrong, you might find that your oldest backup is only three days old. One locked backup from a known-good state is your insurance policy.

Don’t over-automate. A daily restart and daily backup covers 90% of server maintenance needs. You don’t need a task running every 15 minutes. Start simple, add complexity only when you have a specific problem to solve.

Document your schedules. Use descriptive names — “Daily 4AM restart with warnings” is infinitely better than “Schedule 1.” Future you (or your co-admins) will thank present you.

Getting Started

If you’re new to automation, here’s a minimal setup that covers the essentials:

1. Create a daily restart schedule at your lowest-activity hour with player warnings.
2. Create a daily backup schedule 30 minutes before the restart.
3. Lock one backup immediately as your baseline.
4. Check the dashboard after 3 days to confirm everything is running.

That’s it. Four steps, maybe 10 minutes of setup, and your server maintenance is handled indefinitely.

---

For step-by-step setup instructions, see our documentation: Schedules and Auto-Restarts and Managing Backups.

---

For more detailed documentation on schedules, backups, and server management, visit witchly.host/docs. If you run into any issues or want advice on your specific setup, the community at discord.witchly.host is always happy to help.