Palworld 24/7 Server: Autostart, Crash Restart

"Running 24/7" isn't one setting. It's three different mechanisms that fail in three different ways, and leaving any one of them out means the server goes dark in exactly that spot. This covers all three, what memory actually does on a server that stays up, how to restart without losing the save, and the opposite question: whether the world should run at all while nobody is on. If the server doesn't exist yet, build it first with the setup guide.

Three things 24/7 actually means

Here is the whole problem in one table: three ways a server stops being up, each stopped by something different.

None of the three substitutes for another. Restart=on-failure has nothing to do with booting — that's what enable does. enable won't revive a process that died an hour ago. And neither of them does anything at all while memory slowly fills up, because during that stretch nothing has failed yet.

There's a fourth item that needs a person: finding out. Do all three and you still get the night when all three miss, and then the only question is who notices first, and how long after.

What the systemd unit covers, and what it doesn't

The unit file is the one from the setup guide, plus two lines added to its [Unit] section. These are the lines that matter here:

[Unit]
StartLimitIntervalSec=600
StartLimitBurst=5

[Service]
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

WantedBy=multi-user.target plus sudo systemctl enable palworld is what gives you start on boot. In the guide's enable --now, the --now only means "and start it right now" — if you ever start without enable, the server runs fine today and is simply absent after the next reboot. That failure can't be reasoned about, only tested: pick an hour with nobody on and actually run sudo reboot, then check it came back by itself.

What Restart=on-failure does cover: a non-zero exit code, and death by signal. The kernel killing the process for running the machine out of memory counts as the second one.

What it doesn't cover, three cases:

1. A clean exit (code 0). A server brought down through the REST API exits cleanly, so on-failure deliberately leaves it alone. Nine times out of ten, "my restart script stopped the server and never started it again" is this.
2. Alive but not answering. systemd watches a process, not a game. A server that accepts connections while nobody can move is still active as far as the unit is concerned.
3. Repeated failures. The two StartLimit lines make systemd give up after 5 failed starts within 10 minutes and leave the unit in failed. systemd's own default is 5 within 10 seconds, which a unit that waits RestartSec=10 between tries can never reach — without those lines, a server that dies the same way every time just loops, showing activating (auto-restart) forever. When systemctl status palworld says "start request repeated too quickly", auto-restart is not broken — it's telling you the server dies the same way every time and the log is where the answer is.

Don't paper over that third case by deleting those lines or setting StartLimitIntervalSec=0. All it buys is a server that can't load a corrupted save retrying every ten seconds forever, while the real reason scrolls thousands of lines out of reach. journalctl -u palworld -n 100 and reading the last failure is always faster.

What memory does on a server that stays up

Palworld servers earned a reputation during Early Access for climbing until the process was killed, and most advice about restarts still assumes that. Here is what one of the busier servers we run actually did over ten days in October 2026. It restarts once a day, and the figures are its memory use as recorded by monitoring.

Two things in that are worth more than any rule of thumb:

• It climbs while people play, and stops when they don't. A typical day added 0.5–1.5 GB between restarts. On a quiet day the line sat flat around 3.2 GB for hours.
• The daily peak didn't creep up from one day to the next. Each restart put it back on the same floor.

What these numbers can't tell you is what happens if you never restart, because every server we run restarts daily. Whether yours keeps climbing on your world is something to measure, not assume, and the daily restart is cheap insurance either way: it puts the floor back every night and gives saves and updates a known moment.

Where the memory goes

A Palworld server's memory has three parts, and they answer different questions:

1. Base footprint. What the server holds from the moment it starts, and more of it since 1.0: offshore bases brought pathfinding for swimming and flying Pals, and Sky Islands and the World Tree are extra loaded zones. That's the floor.
2. Players online. View distance and explored area. Some of it comes back after logout, not all.
3. What has piled up in the world. Bases, structures, working Pals, dropped items — all of it stays simulated after players log off. This is the slice that grows with the life of the world: people who quit don't take their bases with them.

The first two decide how much RAM you need for a full evening. The third, plus whatever the engine doesn't hand back, decides how often a restart is worth it.

Reading your own server

If a restart changes nothing, look elsewhere: either the machine was never big enough, or what everyone is feeling is the network rather than the server. Server lag: find the cause first sorts those out, starting from who's affected and ending at the server's own frame rate.

The out-of-memory kill is the damaging one: the process may be mid-save when the kernel kills it, and a half-written Level.sav only reveals itself on the next start. That's why memory and backups belong in the same conversation.

Settings that change how much it holds

All of these sit inside the one line in PalWorldSettings.ini (editing it safely is in every option explained):

And a few things not to do: don't disable bIsUseBackupSaveData (it's a way back on the day something breaks, not a memory cost), don't set ServerReplicatePawnCullDistance below 5000 (the official minimum; below it players see frozen Pals), and don't run two Palworld servers on one machine.

How often to restart

There's no interval to read off a spec sheet. It depends on how fast your world eats headroom, and that comes down to how much has been built, whether raids are on, and whether people are online around the clock. Start from once a day and let what you measure move you:

For a regular group the practical answer is one restart a day at an hour nobody plays. Public servers with people on around the clock are the ones that may need it more often.

Announce, count down, save, then stop

Killing the process — kill, systemctl kill, the power button — manufactures one crash a day. You lose up to one autosave interval of progress, and on a bad day you catch the server mid-write and get half a Level.sav, which doesn't announce itself until the next start.

A proper stop is four steps: announce → count down → force a save → stop, all of them in the official REST API. Enable it in PalWorldSettings.ini, and only on localhost:

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="a-long-password"

Authentication is HTTP Basic: the username is always admin, the password is AdminPassword. The developers state plainly that this API isn't designed to face the internet, so don't open 8212 in the firewall. RCON is deprecated, so don't build new scripts on it; the full endpoint list is in the REST API guide.

PW='a-long-password'
API='http://127.0.0.1:8212/v1/api'

# put the world on disk first
curl -s -u "admin:$PW" -X POST "$API/save" -d ''

# the API does the announcement and the countdown for you
curl -s -u "admin:$PW" -X POST "$API/shutdown" \
     -H 'Content-Type: application/json' \
     -d '{"waittime":60,"message":"Server is going down in 60 seconds"}'

The message isn't a chat line people can scroll past. It lands as a banner across the middle of every screen:

/stop is the immediate one, with no warning — don't build routine operations on it. /shutdown waits the time you give it and then goes down properly. The save comes first because the official reference doesn't say whether shutdown saves on its own.

And here the trap from the systemd section closes. A process that went down through /shutdown exited cleanly, so Restart=on-failure will not bring it back. If the goal is a restart, use the API only for the save and the announcement and hand the last line to sudo systemctl restart palworld. If the goal really is a stop — maintenance, moving house, a week nobody plays — /shutdown alone is right. Mixing the two up is the single most common reason a server goes down at 4am and never comes back.

The daily restart as one script

#!/bin/bash
# /home/palserver/restart.sh — announce, save, restart
PW='a-long-password'
API='http://127.0.0.1:8212/v1/api'

curl -s -u "admin:$PW" -X POST "$API/announce" \
     -H 'Content-Type: application/json' \
     -d '{"message":"Server restarts in 5 minutes for maintenance"}'
sleep 240
curl -s -u "admin:$PW" -X POST "$API/announce" \
     -H 'Content-Type: application/json' \
     -d '{"message":"Saving and restarting in 60 seconds"}'
sleep 60
curl -s -u "admin:$PW" -X POST "$API/save" -d ''
sleep 10
sudo systemctl restart palworld

The script holds the admin password, so chmod 700 it. In cron, every day at 4am:

0 4 * * * /home/palserver/restart.sh >> /home/palserver/restart.log 2>&1

If you'd rather keep everything in systemd, use a timer:

# /etc/systemd/system/palworld-restart.timer
[Unit]
Description=Restart Palworld daily

[Timer]
OnCalendar=*-*-* 04:00:00

[Install]
WantedBy=timers.target

A palworld-restart.service of the same name (Type=oneshot) calls the script, and sudo systemctl enable --now palworld-restart.timer turns it on. systemctl list-timers shows the next run. Don't add Persistent=true. That option catches up a run the machine slept through by firing right after boot, and a server that came up two minutes ago has no reason to restart. Pick an hour with nobody on, and make sure it isn't the hour a backup runs.

Windows is the same idea: Invoke-RestMethod in PowerShell to hit announce and save, Stop-Process on PalServer-Win64-Shipping, start PalServer.exe again, and hand the script to Task Scheduler for a daily run.

Since the server stops once a day anyway, that stop is the cheapest place to check for a new game build. Adding the check, the backup that has to sit in front of it, and what to do when the world won't load on the new build are in updating a Palworld dedicated server without losing the save.

How you find out it went down

The default monitoring is "a player tells you", and that alert arrives as five people waiting on a Friday night. Three cheaper options:

One line of status. systemctl is-active palworld prints active or failed and nothing else. For the reason, pull today's exits out of the journal:

systemctl is-active palworld
journalctl -u palworld --since today | grep -i "main process exited"

The port. The game port is UDP 8211, so you can't check it by opening a browser. ss -lunp | grep 8211 tells you whether anything is actually listening.

A one-minute heartbeat. A local cron polls /metrics every minute and, when that fails, sends one line somewhere you actually look. cron doesn't see the PW you set in your shell, so the password lives in a small script and the crontab line only calls it:

#!/bin/bash
# /home/palserver/heartbeat.sh — cron runs this every minute
PW='a-long-password'
curl -sf -m 10 -u "admin:$PW" http://127.0.0.1:8212/v1/api/metrics >/dev/null || /home/palserver/alert.sh

-m 10 makes a server that's up but not answering count as down too. chmod 700 /home/palserver/heartbeat.sh before you put it in cron:

* * * * * /home/palserver/heartbeat.sh

What you should not do is open 8212 to the internet so an external uptime service can poll it. The trade is monitoring in exchange for handing over full admin of the server. Keep the heartbeat inside the machine and let only the notification out.

Auto pause means two different things

Sometimes the question is the opposite one. You log back in after a day away and half the Pals are starving, two are sick, and a chest is full of ore nobody asked for. Nobody was online all day; the world ran anyway. A dedicated server doesn't go idle when the last player disconnects — it ticks the world on the same schedule it uses with a full house. That's what keeps it joinable at any hour, and it's also why it keeps aging at every hour nobody joins. If your group came from hosting inside the game, where quitting stops the world, this is the habit that breaks (which route keeps the world where).

"Auto pause" gets recommended for this, and it describes two different features. Pausing the meter: nobody is online, so the server isn't billed for that stretch; the world usually stops as a side effect, but the feature is sold on price. Pausing the world: game time stops advancing, Pals stop eating, crops stop growing, raids don't fire. Two questions settle which one you're being offered: does the world advance while it's paused, and how long is it before someone can play again.

How auto pause actually works

Most auto pause setups freeze the process with two operating-system signals:

kill -STOP <pid>   # freeze the process where it stands
kill -CONT <pid>   # let it carry on

SIGSTOP isn't a Palworld command and the game never hears about it. The kernel simply stops scheduling that process; it keeps its memory, its files and its UDP port, and SIGCONT resumes it from the exact instruction it stopped on.

Three things have to be built around those two lines before it's safe. Force a save before freezing: SIGSTOP can't be caught, so whatever wasn't on disk stays in memory, and a power cut takes it. Something has to watch the network: a frozen process can't notice a player arriving, so something else, running as root, sniffs for the packet and sends SIGCONT. Something has to keep it listed: the server's heartbeat to the game's backend stops with it, so a frozen server drops off the community server list unless something impersonates it.

None of this is a feature Pocketpair ships: the official REST API has /save, /shutdown, /stop, /announce, kick and ban, and no pause. It's a reasonable trade on a machine in your house, where the point is the power bill. On a server you pay someone else to run, you're buying those three moving parts to get a result you can have another way.

The simpler version: stop it

What almost everyone wants from "pause" is the world isn't running while we're not playing. Stopping the server does exactly that: the world goes to disk, game time can't advance because nothing is executing, and starting back up resumes from the save. The safe sequence is the save-then-/shutdown pair from the section above. The honest cost is that coming back is a start plus a world load, not a second; for a group that plays evenings, whoever gets there first starts it.

Automating the stop

If you want it to happen on its own, the part to automate is the stop, not the freeze: a timer that asks the server how many people are on, every five minutes.

#!/bin/bash
set -o pipefail
PW='a-long-password'
API='http://127.0.0.1:8212/v1/api'
STATE=/var/lib/palworld-empty-rounds
MAX=6   # 6 rounds x 5 minutes = 30 idle minutes

n=$(curl -sf -u "admin:$PW" "$API/metrics" | jq -r '.currentplayernum') || exit 0
case "$n" in ''|*[!0-9]*) exit 0 ;; esac   # not a number? do nothing
[ "$n" -gt 0 ] && { rm -f "$STATE"; exit 0; }

rounds=$(( $(cat "$STATE" 2>/dev/null || echo 0) + 1 ))
echo "$rounds" > "$STATE"
[ "$rounds" -lt "$MAX" ] && exit 0

curl -s -u "admin:$PW" -X POST "$API/save" -d ''
curl -s -u "admin:$PW" -X POST "$API/shutdown" \
     -H 'Content-Type: application/json' \
     -d '{"waittime":10,"message":"Nobody online, shutting down"}'
rm -f "$STATE"

The trap is the first two checks. A failed poll is not an empty server, but a pipe reports the exit code of jq, not curl, and jq answers a dead endpoint with null and exits happily. Without pipefail and the digit check, null is "not greater than zero" and a server with ten people in it goes down because a port hiccuped. The counter lives in a file so a reboot doesn't leave half a countdown behind.

The hard half is coming back. Nothing here can start the server again, because a stopped machine has nothing listening to hear you ask. Stopping is a cron job; starting is a decision someone makes — which is the whole reason the freezing route exists.

You may not need either

If what actually bothers you is narrower than "the world ran", the settings file gets at it directly, and unlike pausing these apply while you play too: PalStomachDecreaceRate slows how fast Pals get hungry (the misspelling is the game's), bEnableInvaderEnemy stops raids on a base nobody is defending, and WorkSpeedRate slows how much the base produces while you're away.

Two hard limits on a machine at home

Power. One outage is one kill -9, with a chance of landing mid-save. A UPS buys minutes, and minutes are only useful if something spends them shutting down in order — which means wiring the UPS monitoring daemon to call the stop sequence above when it sees the power go out. Whether the machine turns itself back on when the power returns isn't an OS setting either; it's the power-restore option in the BIOS. Like the reboot test, this one only counts if you actually pull the plug once.

A dynamic IP. Residential connections change their public address without warning, and the moment it changes every address:port your friends saved is a dead address. DDNS can keep a hostname pointed at the right place, but what the Palworld client stores is the string that was typed, so everyone still re-enters it once. Stack router reboots, upstream bandwidth and carrier-side address sharing on top and the diagnosis gets long — the order to work through it is in connection troubleshooting.

Neither of these is a configuration problem you can out-configure. A home machine will happily hold a server up for a few days; holding one up unattended for months is where power and the line keep getting in the way.

Common questions

How do I keep a Palworld server running 24/7?

Set up three things separately: enable the systemd unit so it starts on boot, put Restart=on-failure in the unit so a crash brings it back, and schedule one restart a day with a timer or cron. Each one covers a different failure — with only one of them in place, the other two situations still leave the server down.

Can a Palworld server restart itself after a crash?

Yes. Restart=on-failure with RestartSec=10 in the unit's [Service] section brings it back ten seconds after a crash or an out-of-memory kill. Add StartLimitIntervalSec=600 and StartLimitBurst=5 to [Unit] as well, so a server that fails the same way every time stops after 5 tries in 10 minutes instead of looping forever. If it's firing several times a day, look at memory just before each crash and at the log, not at the restart policy.

My auto restart is set up but the server didn't come back. What do I check?

Start with systemctl status palworld. "Start request repeated too quickly" means the server failed 5 times within 10 minutes and systemd stopped trying; the real cause is in the log. Once it's fixed, sudo systemctl reset-failed palworld clears the count so it can start again. A status stuck on activating (auto-restart) means the StartLimit lines are missing and it's looping. A quiet inactive with no error usually means the server exited cleanly, which on-failure is designed to ignore — change the last line of your script to systemctl restart.

Why does a Palworld server's memory keep growing?

Mostly because the world keeps more in it while people play: players' explored areas, and the bases, working Pals and dropped items that stay simulated after everyone logs off. On a busy server we run that restarts daily, a typical day added 0.5–1.5 GB, a quiet day stayed flat, and the daily peak stayed between 3.3 and 4.5 GB without creeping up across ten days. A daily restart puts it back on the floor each night.

How often should a Palworld server restart?

Once a day at a quiet hour is where to start. The test is how much headroom is left right before the restart — under a fifth means turn raids off first, then shorten the interval or add RAM.

Will more RAM stop my Palworld server crashing?

Only if it's running out of memory at its peak. Check memory right before the daily restart: if the peak leaves room and the server still crashes, more RAM won't change it, and the log or dmesg will say what did. If the peak is pressing against the limit, more RAM is exactly the fix.

Is auto pause a built-in Palworld feature?

No. The dedicated server has no pause command and the official REST API has no pause endpoint. Anything sold as auto pause is done from outside the game — either by freezing the process with an operating-system signal, or by stopping the server and starting it again on demand.

Will pausing the server stop my Pals from starving?

While it's paused, yes — nothing in the world advances, including hunger. It doesn't change anything about the hours you are playing, though. If the goal is to stop coming back to an empty feed box, PalStomachDecreaceRate does it without stopping anything.

Can I run a Palworld server 24/7 on a home PC?

For a few days, yes. Over months, power outages and a dynamic IP are what stop it: an outage is an unannounced kill that can corrupt a save, and a changed public address invalidates the connection details everyone saved. Neither is fixable in config, so a permanent server wants a machine whose power and network someone else keeps up.

Where the three land on hosting

Map all of this onto a hosted server and it comes out like this. Start on boot stops being a step — the machine and the game process are handed over together. A crashed process is brought back automatically. Daily scheduled restart sits in the server's detail page under My servers in the Console as a switch and a time; shortly before it comes round, the server posts an in-game announcement, counts down, forces a save, and only then restarts. Stopping and starting by hand is a button on the same page and runs the same announce-save-shutdown sequence, so "just stop it for the week" is a habit rather than a gamble. Backups run on a schedule (what goes into a complete one), and frame rate and player count are recorded every minute, so the stretch a server was down shows up as a gap rather than something you grep for.

What isn't there is an automatic idle stop: nothing watches the player count and stops the server for you. That's how these controls look with Palworld server hosting from KeepWorlds. If you build your own instead, the checklist is identical: one enable, one Restart line, one daily restart that saves first, and one way to find out.