Scheduled tasks on a game server, and failing safely

Every server accumulates jobs that should happen without anyone remembering: backups, restarts, updates, cleanup. Getting them onto a schedule is straightforward. Getting them onto a schedule that fails safely is the part that takes thought.

What is actually worth scheduling

And a category worth resisting: anything that changes the game world on a timer. Automated wipes, automated resets, automated pruning of player builds. Those are decisions, and a decision made by cron at 4 a.m. is a decision nobody reviewed.

Restarts: what they actually fix

A scheduled restart is standard practice and worth understanding rather than cargo-culting.

What it genuinely helps: memory that the server does not release, entity counts that creep up, plugin state that drifts, and applying config changes that need a fresh start.

What it does not help: a server that is slow because the CPU is too slow, or because a plugin is doing something expensive every tick. A restart hides those for an hour and they return.

If your server needs a restart every six hours to stay usable, the restart is not the fix. It is a symptom worth investigating, usually a leak in a specific plugin, and bisecting to find which one is a better use of the time.

Daily is a reasonable default. Announce it in advance in chat — thirty seconds of warning turns an outage into a pause.

Where to run the schedule from

Three options, and the choice matters more than it looks.

Host cron. Reliable, survives everything, and can act on the server process itself. The right answer for most setups.

Inside the container. Frequently does not work, because a container runs one process and no cron daemon. This surprises people who moved to containers and found their scheduled jobs silently stopped.

The game server's own scheduler. Plugins that restart the server on a timer. Convenient, and dependent on the server being healthy — which means it cannot restart a server that has hung, and a hung server is exactly when you wanted it to.

The rule that follows: anything that has to work when the server is broken must run from outside the server.

Making failure visible

A scheduled job that fails silently is worse than no job, because you believe it is running.

The specific way this bites: backups. A backup that has been failing for six weeks looks identical to one that has been working, right up until the moment you need it. Nobody notices, because success and silence look the same.

Two cheap fixes:

Log to somewhere you look. Cron mails output by default on most systems, which nobody reads. Redirect to a file, or better, into your Discord via a webhook. A daily line saying "backup: 2.4 GB, ok" is boring and it is how you know.

Alert on absence, not on failure. A job that crashes hard may not log anything at all. A check that says "the backup file is older than 26 hours" catches crashes, hangs, and the case where the machine was off.

Ordering and collisions

Jobs that run at 3 a.m. because 3 a.m. sounded quiet all run at 3 a.m. On a two-core box, a backup, a log rotation and an update check starting simultaneously is a load spike at the exact moment your world is being copied.

Stagger them. And put the backup first, before anything else touches the files, so that if the update goes wrong you have a copy from before it.

The PageSpeed and SEO sweeps here run at 02:30 for the same reason — one time, deliberately chosen, with nothing else scheduled against it.

Backups deserve their own rules

Take them while the server is running, or stop it properly. A world copied mid-save is a corrupt world that restores cleanly and then fails. Most server software has a command to flush and pause saving; use it, copy, resume.

Copy off the machine. A backup on the same disk protects against your mistake and not against the disk. The failure that takes both copies is the one that happens.

Test a restore. Not theoretically — actually restore one, into a test instance, once. The number of backup arrangements that have never been restored and do not work is very high, and there is exactly one way to find out.

Automated updates: be careful

The obvious cron job is a nightly app_update. It is also how a populated server gets its binaries rewritten underneath it.

The version that works stops the server first, checks whether an update exists before stopping anything, and announces. The details are in SteamCMD and app IDs, and the summary is that "update automatically" and "update unattended" are different levels of risk.

For plugins specifically, automatic updates are worth avoiding entirely. They are the most common cause of a server that worked yesterday and does not today.

What not to automate

Anything irreversible without review. Deleting player data, pruning builds, resetting economies.

Anything that needs judgement. A ban expiring is fine; a ban being issued is not.

Anything you cannot explain in a month. A cron job whose purpose you have forgotten is a liability, and every long-running server accumulates one. Comment them.

The short version

Backup daily and restore-test it once. Restart on a schedule and investigate if you need to restart often. Run anything that must work when the server is broken from outside the server, stagger jobs so they do not collide, and make failure visible by alerting on absence rather than on error.

And keep the automation to things that do not require judgement. A decision made by cron is a decision nobody made.