Palworld Server Lag: Find the Cause First
Palworld dedicated server lag is four unrelated faults sharing one word. Sort them with three questions, then read the server's own frame rate to settle it.
"The server is lagging" arrives as one sentence and covers at least four unrelated faults. They feel similar from inside the game and they are fixed in completely different places, which is how people end up paying for more RAM to cure what was a Wi-Fi problem, or moving the server to another country to cure a memory leak.
This page is the route, not the repair: three questions that sort most reports in about a minute, then one number that settles whatever is left, then where each cause gets fixed. Every branch ends at the article that goes deep on it.
Step 1: is it the server at all?
Before touching a setting, work out whose problem it is. Two questions do almost all of the sorting — is anyone else feeling it, and does the picture stutter or do your inputs land late — and they separate the four cases cleanly.
| What you see | Whose fault | Where it gets fixed |
|---|---|---|
| Your inputs land half a beat late; everyone else is fine | Your connection | Ping, regions and the three kinds of lag |
| The picture stutters but inputs land instantly; everyone else is fine | Your own PC | "Client FPS drop is a different number", below |
| Everyone rubber-bands at the same moment | The server | Step 2, below |
| Nobody can connect, the server isn't in the list, people drop at random | Not lag at all | Can't connect: fixes in order |
The third row is the only one this article is really about. The other three are someone else's problem in the literal sense: no setting on the server will move them.
One shortcut worth knowing before the work starts: if a restart makes it good again instantly, the machine is not too small. That single test rules out the most expensive wrong answer, and it points straight at the engine's memory leak.
Step 2: read the server's own frame rate
A Palworld server has a frame rate of its own, and it is the difference between "it feels laggy" and a number you can act on. It comes from the official REST API, which the server exposes on localhost once you enable it (setup and the one security rule are in the REST API guide):
curl -s -u "admin:$PW" http://127.0.0.1:8212/v1/api/metrics
{"serverfps":13,"serverframetime":76.9,"currentplayernum":4,
"maxplayernum":16,"uptime":259200,"days":137,"basecampnum":11}
A Palworld dedicated server runs at 30 frames per second when it's healthy, not 60. That surprises people who assume the server matches their client, and it is the reason a reading of 28 is nothing to worry about. What the number means:
serverfps | What the players feel |
|---|---|
| 25–30 | Healthy. Nothing to fix here — look at Step 1 again |
| 15–25 | The first complaints. Combat feels sticky, nobody can say exactly why |
| Under 15 | Everyone feels it: rubber-banding, Pals frozen mid-task, late hits |
| Single digits | Unplayable, and usually minutes away from the process dying |
Three other fields in that response earn their place in the same glance:
serverframetimeis milliseconds per frame, roughly the inverse of the frame rate — 30 fps is about 33 ms. Its value is that spikes show up here before the average frame rate moves, so it's the field that catches a server that's fine on average and hitches every few seconds.uptimeis seconds since the process started. It's the evidence for the leak: pair a low frame rate with a large uptime and you have your answer before measuring anything else.basecampnumis how many bases exist in the world. Of everything the API reports, this is the number that tracks the frame rate most closely — worlds don't get heavy because more people joined, they get heavy because more has been built.
Take the reading while someone is complaining. A number from a quiet morning tells you nothing about a Saturday night.
Step 3: four things that pull server FPS down
In the order they actually turn up. Each one has a test that rules it in or out in under a minute.
1. Uptime — the memory leak. The server's memory only climbs, the frame rate sags with it, and the process eventually gets killed by the OS. The test is the restart: good again immediately means this is it. It is the most common cause by a wide margin, more RAM only spaces out the crashes, and the fix is a scheduled restart — intervals, the announce-save-stop-start order and a script are in memory leak and scheduled restarts.
2. The world got heavy. Bases, structures, working Pals and dropped items all stay simulated after everyone logs off, and none of it goes away on its own. The test is basecampnum plus a look around: a world with a dozen bases and every base fully staffed is doing several times the work it did in week one. Four settings move this directly — bEnableInvaderEnemy, BaseCampWorkerMaxNum, BaseCampMaxNum and DropItemAliveMaxHours (every option explained) — and raids are the one to switch off first.
3. Peak hours — the main thread. Physics, pathfinding, combat and state sync all run on one thread, so clock speed decides your ceiling and extra cores barely help. The test is the shape of the curve: fine at four players, sagging at ten, back to normal when people log off. That's a sizing problem against your player count, not a leak — server requirements covers what to size against, and why a player cap is more than one number is in player limits.
4. A rhythmic hitch — the disk. Everyone freezes for a fraction of a second, at a regular interval, and it has nothing to do with how busy the server is. The test is the clock: if the hitch lines up with AutoSaveSpan (30 seconds by default), it's the autosave meeting a slow disk. This one gets misdiagnosed as a network fault constantly. An SSD ends it.
If two of these are true at once — and after a few months they usually are — fix them in this order anyway. The restart is free and rules out the biggest one.
Where you read this on a hosted server
On a dedicated Palworld server from KeepWorlds, the frame rate and player count are sampled every minute and drawn in Server health in the Console: a 24-hour line for each, Average FPS and Lowest FPS, and an Alert line at half of full speed so you can see at a glance whether 13 counts as low on this game. Reading the two curves against each other is Step 3 without the curl: a frame rate that sags as the player count climbs is the main thread, one that sags while the player count is flat is the leak or the world's weight. The gaps in the line are the stretches when the server was stopped — including Daily scheduled restart, which handles cause 1 on its own.
Client FPS drop is a different number
Two frame rates share one name, and mixing them up sends people to change settings on a machine that was never the problem. Your client's FPS is what your graphics card draws. The server's FPS is how fast the world is simulated. They move independently.
The distinction is one question: do your inputs still land instantly?
| Symptom | Which frame rate | What to do about it |
|---|---|---|
| Picture stutters, swings and menus respond instantly, friends are fine | Your client | Graphics settings, on your machine |
| Picture is smooth but hits land late, and everyone says so | The server | Step 2 above |
| Both, at once, and only in one place in the world | Both — a heavy base is heavy for everyone | Step 3, cause 2 |
That last row is the one worth knowing. A base with hundreds of structures and a full crew of working Pals costs the server simulation and costs your GPU rendering, so the same spot on the map tanks both numbers. People report it as "the server lags at my base" and go hunting on the wrong machine.
For a client-side drop the levers are all local — graphics preset, resolution scale, and closing whatever else is using the GPU — and a dedicated server can't help with any of them. What it can do is make sure the other half of the equation is healthy, which is what the rest of this page is about.
Lag that tuning won't fix
Two cases don't belong to the server at all, and no amount of settings work touches them.
- High ping or packet loss. Palworld runs over UDP and doesn't resend what goes missing, so above roughly 1% loss you rubber-band no matter how good the average looks. Measuring it, reading jitter, and picking a region for a group spread across countries are in ping, regions and the three kinds of lag.
- A version mismatch. After a game update, a server on the old build doesn't feel slow — it locks everyone out, and the failure reads like a network problem. Updating without losing the save covers the order that keeps the world intact.
Common questions
Why is my Palworld server lagging?
Check who's affected first. If it's only you, it's your connection or your PC. If everyone rubber-bands at once, restart the server: good again instantly means the engine's memory leak, which is the most common cause by far. If the restart changes nothing, read serverfps from the REST API while people are complaining — a sag that tracks the player count is the CPU's main thread, a sag with the player count flat is a world that has grown heavy.
What is a normal server FPS on a Palworld server?
30 is full speed for a Palworld dedicated server, so anything from 25 up is healthy. Between 15 and 25 the first complaints start; below 15 everyone in the world feels it, with rubber-banding and Pals frozen mid-task. Read it from /metrics on the REST API, and read it while the server is busy rather than at a quiet hour.
Is the FPS drop my PC or the server?
Ask whether your inputs still land instantly. A stuttering picture with instant, responsive controls is your graphics card, and nobody else will be seeing it. A smooth picture with hits that land late is the server, and everyone will be seeing it at the same moment. If both go at once and only in one part of the map, it's a base heavy enough to cost the server and your GPU at the same time.
Do more bases make a Palworld server lag?
They're the single biggest thing a group does to its own server. Bases, their structures and their working Pals keep being simulated after everyone logs off, so the load tracks what has been built far more than how many people are online — and the basecampnum field in /metrics is the number to watch. Capping bases and workers per base, and turning off raids, are the three most direct levers.
Diagnosis you don't have to run
Everything above assumes someone is available to take a reading at the moment people are complaining — which is exactly when nobody is free to SSH in. That's the real difficulty with server lag: the evidence is only there while it's happening, and by the time anyone looks, the server is idle again and reads perfectly healthy.
On a Palworld server from KeepWorlds the readings are already taken — frame rate and player count every minute, kept as a 24-hour curve with an alert line, so "it was awful last night" is something you look at rather than reconstruct. The most common cause is handled before you get there: the Daily scheduled restart clears the leak at an hour you pick, with an in-game announcement and a forced save first. And the settings that drive the other causes — raids, base limits, workers per base — are fields in the game settings form, not a line of .ini you edit over SSH.
Read this in another language
Rather not run it yourself?
Pick a game and a plan, and your server launches on a machine of its own. Backups, game updates and expiry reminders are on us.
See Plans