Why your game server keeps restarting, and how to fix it

A server that restarts on its own is one of four things, and they are worth telling apart before you change anything: it ran out of memory, it crashed on something in its own files, it was restarted by a schedule or a watchdog, or the game itself refused to keep running. Each has a distinct signature in the console and a distinct fix, and the reason people spend a weekend on this is that they start by changing settings instead of by reading two lines. The two lines are the exit code and the last thing printed before it. Almost everything below follows from those.

Narrowing it down in one minute#

Before any theory, collect three facts: when it happened, what the exit code was, and what the memory graph looked like in the two minutes before. That is usually enough.

The last two rows are the most useful distinction in the whole post. A leak kills a server on a clock - every six hours, every nine hours, whether two people are online or twenty. A shortage kills it when the world is busiest. They both look like "out of memory" and they have different fixes.

Exit codes: what actually ended the process#

Every restart has a number attached to it, and the number is not ambiguous.

One caveat on 137: it is also what you get from a Kill button or a manual kill -9. If nobody pressed anything, it is the memory limit. Check the kernel's own record if you have shell access:

$ dmesg -T | grep -i "killed process"$ cat /sys/fs/cgroup/memory.eventslow 0high 0max 4812oom 19oom_kill 19

oom_kill greater than zero is a fact rather than a theory. Nineteen kills is nineteen restarts you did not ask for.

Out of memory, the common one#

When a container reaches its memory limit the kernel stops it, and it comes back clean. That is deliberate on RE:NODE - upstream Pterodactyl ships the opposite, where a container at its ceiling sits and swaps and drags the whole machine down with it. A short outage that recovers by itself beats a slow decline that takes the neighbours with it. The cost of that choice is what you are reading about: the process gets no notice and writes no goodbye note, so the console just ends.

There are two separate memory ceilings and they produce different evidence:

• The runtime's own limit. A JVM that exceeds -Xmx throws java.lang.OutOfMemoryError: Java heap space, which is logged, often repeatedly, and the server frequently limps on for a while in a broken state. A Node process aborts with FATAL ERROR: ... JavaScript heap out of memory and exit code 134. Both of these print something.
• The container limit. Nothing is printed, because nothing gets the chance. Exit code 137, a vertical memory graph, and silence.

The single most common self-inflicted version is a heap set to the whole plan. -Xmx4G inside a 4 GB container will be killed, because the JVM needs memory outside the heap for thread stacks, metaspace, direct byte buffers, the JIT code cache and the collector's own structures. Set -Xmx to about 80-85% of the container limit, leaving at least 512 MB free and a full gigabyte on anything modded. Minecraft JVM flags and Java versions has the full flag set, and Node.js memory limits is the same problem for applications, which have their own separate ceiling.

Then work through it in this order, because the cheapest fixes are first:

1. Check the heap setting against the container limit. More servers are killed by a misconfigured heap than by a genuine shortage, and fixing it costs nothing.
2. Reduce what is loaded. Lower view and simulation distance, shrink the world border, pre-generate rather than generating live, clear accumulated entities. Every chunk you do not hold is memory you do not need.
3. Find the leak before you feed it. Memory that climbs forever under constant load is a plugin or a mod, and a bigger plan just moves the deadline.
4. Then buy memory. It is the one problem more memory genuinely solves.

CPU or RAM: which one is actually holding your server back separates this from the case where the memory graph is a red herring, and Linux swap and the OOM killer explains what the kernel is actually doing.

Crashing on its own files#

If there is a stack trace, read it upward rather than at the end. The last line is where the process gave up; the cause is usually ten to forty lines above it, and it is the first line that names something you installed rather than something the game ships with. In a Java trace, follow the Caused by: chain to the bottom - the final one is the root.

[21:14:07] [Server thread/ERROR]: Could not pass event PlayerJoinEvent to ShopPlus v3.2java.lang.NoSuchMethodError: org.bukkit.inventory.ItemStack.getItemMeta()    at net.example.shopplus.JoinListener.onJoin(JoinListener.java:64)    ...Caused by: java.lang.ClassNotFoundException: com.example.vaultapi.Economy

That reads as: a plugin called ShopPlus broke, because it was compiled against a different version of the game, and because a dependency it needs is not installed. Neither fact is in the last line.

The four things that produce this class of restart:

• A version mismatch after an update. The game updated, the mods did not. This is the most common crash loop in existence, and it is why a modded server should never auto-update on the day of a patch. Keep a copy of the working mod folder. What to do when a mod update breaks is the recovery.
• Two mods that disagree. Usually visible as an exception naming both, or as a crash that only happens with a particular pair installed.
• A missing dependency. A permissions or economy API that a plugin assumes is there.
• A corrupt world region or save. The tell is that it crashes reproducibly at the same moment: when a specific player logs in, or when a specific chunk loads, or during the save that follows a specific event. Restore from a backup rather than debugging it, and backups that actually restore covers why the backup you have may not be one.

To find the culprit among forty mods, bisect rather than guess. Move the whole folder aside, confirm the server starts clean, then put half back and start. Five restarts narrows forty candidates to one, and it takes about fifteen minutes. Guessing takes an evening.

Restarts you asked for and forgot#

A surprising share of "my server keeps restarting" tickets are a schedule. Check all of these before concluding anything is wrong:

• The panel's own schedules. On RE:NODE these are on the Schedules tab: a cron expression and an ordered list of tasks with delays, which can include a power action. A restart added six months ago is still running. Cron expressions explained covers reading the expression, and scheduled tasks worth having covers what should be there.
• A restart plugin or mod inside the game. Many communities install one and forget it. It will have its own config file and its own schedule, unrelated to the panel's.
• A watchdog. Paper's spigot.yml has settings.timeout-time (60 seconds by default) and settings.restart-on-crash, and a tick that exceeds the timeout causes the watchdog to kill and restart the server with The server has stopped responding! in the log. That is not a crash, it is a stall being treated as one, and the fix is whatever made the tick take a minute.
• Update-on-start. A container that pulls the latest build every boot will loop cleanly if the latest build is broken. Pin a version while you diagnose.
• A process manager on your own machine. A systemd unit with Restart=always or a Docker --restart unless-stopped policy will keep relaunching a process that cannot start, forever, with the reason scrolling past each time.

On RE:NODE there is a per-server activity log, which records power actions and who caused them. That is the fastest way to answer "did something restart this, or did it die". A restart you asked for and one the server did by itself look identical in the console and are entirely different in the log.

The game giving up: credentials, versions and ports#

These fail before the ready line, or exactly once a session, and they are all boring once identified.

• An expired or revoked credential. CS2 and Unturned need a Steam game-server login token, FiveM a Cfx.re key, Don't Starve Together a Klei token, BeamMP an auth key. Steam removes a login token that has gone unused for a long period, and a token attached to a banned server is revoked, so a server that ran for a year can stop being able to go public overnight without anything on your side changing. Steam game server tokens covers creating and replacing one.
• A version mismatch with the client. The server updated and the mods did not, or the client updated and the server did not. The server usually runs fine and nobody can join, which is a different complaint that arrives as the same ticket.
• A port already in use. java.net.BindException: Address already in use, or Minecraft's FAILED TO BIND TO PORT!. On a panel this is nearly always the previous process not having fully exited before the next start, which a full stop and a pause fixes, or two servers accidentally given the same allocation.
• The EULA. A fresh Minecraft server writes eula.txt and exits with code 0 until eula=true is set. Two clean exits in a row with no error is this, every time.
• A full disk. A server that cannot write cannot save, and many games crash rather than continue. Check disk before anything else; it takes one command and it is invisible in the console until the moment it is fatal.

$ df -h /home/container$ du -sh /home/container/* | sort -h | tail -10

Crash loops, and what a host does about them#

Nothing in the daemon tells the panel that a server died, so it has to be inferred. On RE:NODE a watcher polls every two minutes and looks for two signals: uptime that has gone backwards since the last poll, which means the container was replaced in between even if it was never observed down, and a server that was up and is now offline.

• A restart you asked for is not counted. Anything inside the grace window of a logged power action is a button being pressed, not a failure.
• An unreachable node is not fifty stopped servers. A failed poll records nothing and leaves the watcher's memory intact, so a network blip cannot suspend half a machine.
• Three restarts in an hour raises a warning on the server page and opens a support ticket automatically. Six suspends it, and you have been told twice by then.

The suspension exists because a server restarting every ninety seconds is not just broken for you. It re-reads its files, re-registers with whatever it registers with, and generates load out of proportion to what it is doing, which is unfair to everything else on the machine. The warning arriving first is the point: it is meant to reach you while it is still a nuisance.

A server pinned at 100% CPU is not about to be suspended. The container is throttled to the share you bought, so it runs slowly rather than breaking - we say so on the warning rather than letting a red graph imply otherwise.

Breaking the loop: a procedure#

When a server is actively looping, the console overwrites the evidence every ninety seconds. Stop it first, then work.

1. Stop the server properly. Not Restart. A loop you have paused is a problem you can read.
2. Take a backup before touching anything. Diagnosis involves moving files, and moving files involves losing them.
3. Copy out the console. The hundred lines before the first restart, not the last one. The last restart is the least informative instance of the problem. Reading the console covers what to keep.
4. Check disk and memory. One df -h, one look at the memory graph in the two minutes before the death. These two checks rule out the silent causes, and they take thirty seconds.
5. Turn off anything that restarts it. The panel schedule, the restart plugin, restart-on-crash. You cannot read a loop that keeps restarting itself.
6. Start it with nothing added. Mods folder moved aside, config restored to defaults, plugins out. If it starts, the problem is in what you moved. If it does not, the problem is the world, the runtime version, or the machine.
7. Test with a fresh world. This separates a corrupt save from a broken installation in one start, and it is the check people skip for hours.
8. Bisect back in. Half at a time.
9. Open a ticket with the console attached. On RE:NODE a ticket from the panel reaches all staff and takes private attachments, which is the right place for a log that has a token in it.

The habit worth building afterwards: keep the logs. A crash loop is far easier to diagnose when you can compare today's console to a copy from the week it worked. Logs worth keeping covers what to keep and for how long, and keeping a modded server clean covers not getting here again.

FAQ#

My server restarts with nothing in the log. What is it?

Almost certainly the container memory limit. A process killed with SIGKILL cannot run any code, including its own logger, so the console simply stops. Confirm with the exit code - 137 - and the memory graph, which will show a vertical climb into the limit immediately beforehand.

How do I tell a crash from a restart somebody triggered?

The exit code and the shutdown lines. A requested stop produces 143 or 0 and an orderly sequence of saving and shutdown messages. A crash produces a trace, an abort, or nothing at all. The panel's per-server activity log settles who pressed what.

Will a bigger plan stop the restarts?

Only if the cause is a genuine memory shortage at peak. If the server dies after a fixed uptime regardless of how many people are online, that is a leak, and a bigger plan buys proportionally more hours before the same crash. Diagnose first, buy second.

Is an automatic restart every night a good idea?

For most servers, yes. It clears slow accumulation, applies updates predictably, and moves an unavoidable interruption to a time you choose rather than one you do not. Schedule it when nobody is playing and warn people in advance. Restart schedules that help covers doing it without losing anyone.

Why was my server suspended for restarting?

Because six unexpected restarts happened inside an hour, after a warning at three and an automatically opened ticket. It is a protection for the machine and for you - a server in a tight loop is doing damage to nothing except its own availability, but it is doing it continuously. Fix the cause and ask for it to be unsuspended.

The server restarts at exactly the same time daily. Where do I look?

In three places, in this order: the panel's Schedules tab, any restart plugin or mod inside the game, and any external process manager. One of those three is responsible in nearly every case, and an actual fault that keeps to the minute is very rare.