Palworld Auto Pause: How It Works and What It Costs

You log back in after a day away and the base is a mess. Half the Pals are starving, two of them are sick, and a chest is full of ore nobody asked for. Nobody was online all day. The world ran anyway. Auto pause is what gets recommended when you bring that up.

Before you shop on the phrase, it's worth knowing that it describes two different features, and one of them doesn't do the thing you're after.

Auto pause means two different things

Pausing the meter. Nobody is online, so the server isn't billed for that stretch. The world usually does stop as a side effect — something has to be switched off for the charge to stop — but the feature is sold on price, and the details that matter to you are further down: how it goes down, and how long it takes to come back.

Pausing the world. Game time stops advancing. Pals stop eating, crops stop growing, raids don't fire at a base nobody is standing in.

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. The second one separates the implementations more than anything in a feature list.

Why the world keeps moving with nobody online

A dedicated server is a process that just keeps running. It doesn't go idle when the last player disconnects — it ticks the world on the same schedule it uses with a full house. Base Pals keep working and keep getting hungry, crops keep growing, and raid events keep firing at a base with nobody home.

If your group came from hosting inside the game — one person opens the world, everyone joins them — this is the habit that breaks. There the world lives inside that person's game, so quitting stops it. A dedicated server is the opposite arrangement on purpose: it's up so people can join at any hour, which means it's equally up at every hour nobody does. Which route keeps the world where is in Palworld multiplayer options.

How auto pause actually works

The mechanism behind most auto pause setups is 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 open files and its UDP port — it just doesn't execute. SIGCONT starts it again from the exact instruction it was frozen on, and the server has no idea time passed.

Where it sits between the two states you already know:

Three things have to be arranged around those two lines before it's safe to use:

1. Force a save before freezing. SIGSTOP can't be caught, blocked or ignored — that's what makes it reliable, and it also means the server gets no chance to finish anything. Whatever was in memory and not yet on disk stays in memory. If the machine then loses power, that work is gone.
2. Something has to watch the network. A frozen process can't answer a connection, so it can't notice a player arriving. Something else has to sit on the interface, see the inbound packet and send SIGCONT. That's a packet sniffer running as root next to your game server.
3. Something has to keep it listed. The server's own heartbeat to the game's backend stops with it, so a frozen server drops off the community server list. Putting it back means something else has to keep talking to that backend on the frozen server's behalf — impersonating it, with the credentials and the payload it would have sent.

None of this is a feature Pocketpair ships. The official REST API has /save, /shutdown, /stop, /announce, kick and ban — there is no pause in it (the full endpoint list). Everything above is done from outside the game, to a game that doesn't know it's happening, and a server update can change the footing under any of the three steps.

It's a reasonable trade on a machine in your house, where the point is the power bill. On a server you're paying someone else to run, you're buying the three items above and their failure modes 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, with no machinery: the world goes to disk, game time can't advance because nothing is executing, and starting back up resumes from the save.

The sequence that makes it safe is the same one a scheduled restart uses:

PW='a-long-password'
API='http://127.0.0.1:8212/v1/api'
# 1. warn whoever is still on, with a countdown
curl -s -u "admin:$PW" -X POST "$API/announce" \
     -H 'Content-Type: application/json' \
     -d '{"message":"Server going down in 60s, find a safe spot"}'
# 2. force the world to disk
curl -s -u "admin:$PW" -X POST "$API/save"
# 3. graceful shutdown, 60-second countdown
curl -s -u "admin:$PW" -X POST "$API/shutdown" \
     -H 'Content-Type: application/json' \
     -d '{"waittime":60,"message":"Server going down in 60 seconds"}'

The save comes before the shutdown because the official reference doesn't state whether shutdown saves; the same order is in the REST API guide and in the scheduled restart recipe.

The cost, and it's the honest one: coming back is a start plus a world load, not a second. For a group that plays evenings, whoever gets there first starts it and pours a drink. For a server people drop into unannounced, that minute is the whole argument for freezing instead.

Automating the stop

Stopping by hand covers a group that plays evenings. 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, and acts on the answer. Five minutes apart, from a systemd timer or cron.

#!/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"
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"

Two details carry their weight, and the first one is the trap. A failed poll is not an empty server — but a pipe reports the exit code of jq, not of 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 second: the counter lives in a file rather than a sleep loop, so a reboot doesn't leave half a countdown behind.

The hard half isn't in this script — it's coming back. Nothing here can start the server again, because a stopped machine has nothing listening to hear you ask. The options are another machine watching for traffic, a bot with a shell on the box, or someone typing systemctl start. That asymmetry — stopping is a cron job, starting is a decision — is the whole reason the freezing route exists, and also why it has to run a packet sniffer as root.

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're playing too:

Every option, with defaults and the ones that cost performance, is in Palworld server settings explained.

Common questions

Does a Palworld server keep running the world when nobody is online?

Yes. A dedicated server ticks the world whether or not anyone is connected, so Pals keep eating, crops keep growing and raids keep firing on an empty server. The only ways to stop that are freezing the process or stopping the server.

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.

Can a Palworld server stop itself when nobody is online?

Yes. A timer that polls /metrics for the player count and calls /save then /shutdown after enough empty rounds does it in about fifteen lines. Starting it back up is the half that can't be automated the same way — a stopped server has nothing listening to hear the request.

Does stopping a Palworld server lose progress?

Not if you save first. Announce a countdown, POST /save, then shut down — the world on disk is current and starting back up resumes from it. What loses progress is cutting the process off mid-write, which is what a power cut or a /stop with no save does.

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.

Where this lands on hosting

On a dedicated Palworld server from KeepWorlds, stopping and starting is a button in the server's detail page under My servers in the Console, and the countdown-save-shutdown sequence above is what happens behind it: a server announcement in game, the countdown, a forced save, then the machine goes quiet. That's graceful stop, and it's the piece that makes "just stop it" a reasonable habit rather than a gamble.

Two things sit next to it. Backups run on a schedule and the recent ones are kept (what goes into a complete one), so the state you stopped at is recoverable even if the stop itself went badly. And daily scheduled restart is a switch and a time on the same page — for the memory that builds up on a long-running server, which scheduled restarts covers in full.

keepworlds.com/consoleRunning

BackupsBack Up Now

Taken	Size	Type	Actions
2 hours ago	412.6 MB	Auto	Restore
4 hours ago	410.2 MB	Auto	Restore
6 hours ago	398.1 MB	Manual	Restore

Only the 3 most recent backups are listed.

What isn't here is an automatic idle stop — nothing watches the player count and stops the server for you. Someone presses the button. If your group's pattern is "we play Friday and Saturday", that's two presses a week against a world that doesn't age in between. And if you'd rather it never went down at all, the three mechanisms that keep one up are in running a Palworld server 24/7.