Palworld server stuttering — reading server FPS and fixing it

A Palworld world that felt fine last weekend starts hitching every few seconds. Or it plays perfectly on the day you restart it and gets worse each evening until someone restarts it again. Those are two different problems with two different pieces of evidence, and both are visible on your own graphs before you touch a single setting. This guide reads the evidence first, then walks the controls that actually move server FPS on a uniz.host Palworld server — and is honest about the one case where none of them help.

Read the evidence before you change anything

Open your server, stay on the Overview tab, and look at the "Resource usage" charts. Palworld servers get two game charts ahead of the rest: "Players online" and "Server FPS". Palworld reports a server frame rate rather than Minecraft's TPS, so this is the number that corresponds to how the world feels to a player.

Compare server FPS against player count over seven days

Switch the range buttons above the charts to "7d". A single evening tells you almost nothing; a week tells you which of the four shapes you have.

The number to hold on to: our own monitoring judges a Palworld server unhealthy when its server FPS stays below 20 for three minutes in a row. That is a floor, not a goal. Note that this check is a platform-side alert and its notification is off by default, so a slow server never announces itself — reading the graph is the whole diagnostic.

One shape is not a performance problem at all. If the RAM graph carries OOM markers, the server was killed for exceeding its memory ceiling, and no setting on this page fixes that; skip to the RAM section. The dashboard tour explains how to read them.

The Engine performance switch, and what it actually writes

On the Settings tab, the "Version and performance" group has a section headed "Engine performance boost (Server FPS)" with its own switch. Turning it on does something concrete: the platform tells the server image to generate an Engine.ini for your world, and then sends every engine value explicitly rather than only the ones you changed. That second part is deliberate — the game image floats on its latest release, and sending only your edits would let an upstream change quietly retune your server behind your back.

The knob that matters is the headline one, "Server FPS cap (Server Tick Rate)". It accepts 30 to 120 and ships at 120, which is the ceiling the tuning exists to raise. The rest live under "Fine-tuning (Advanced)" and share the same 30–120 range. Four network bandwidth values are also written, pinned high with no knob at all, because a wrong low value there produces rubber-banding that looks exactly like a server fault.

Two things people get wrong about the switch:

• Off really is off. A small init container deletes the generated Engine.ini on every boot, whether the switch is on or off. With tuning on, the image writes the file again before the game starts; with tuning off, the game finds no generated file at all. There is no stale-config state to get stuck in.
• Your numbers survive being switched off. The knob values stay saved while the switch is off, so turning it back on restores the tuning you had, not the defaults.

Turn the Engine performance switch on, then restart

Nothing in that section touches a running server. Press "Save" on the group's save bar, then restart from the server's header — or press "Save and restart" to do both at once. The section's own description says it applies after a restart, and that is true of every Palworld setting here, not just this one.

The success check is the same graph you started with: at a comparable player count, the line in the "Server FPS" chart should now sit higher than it did before. If it does not move at all, the tick ceiling was never your limit — you are CPU-bound, and the honest fix is a bigger plan or fewer things happening in the world.

The auto-save interval, and what you trade for it

On the Settings tab, the "Game rules" group has an "Other" section holding "Auto-Save Interval (sec)". It accepts 30 to 600 seconds in steps of 30 and ships at 30 — the game's own default.

Every autosave serialises the world on the game thread, and at a 30-second cadence that lands as a visible dip in server FPS twice a minute. That is the regular-rhythm shape in the table above. Stretching the interval removes those dips; it does not make the save itself cheaper.

What you pay is rollback. The interval is exactly how much play the server can lose if it crashes between saves. The minimum stays pinned at the game's own 30 seconds, so no value you pick here is worse than stock — but 600 seconds means a crash can cost ten minutes of building.

Stretch the auto-save interval if the stutter arrives in beats

120 seconds is a sensible first move: four times fewer hitches, still only two minutes at risk. Save, restart, then play a normal session and look at the graph again — the dips should be further apart, and if they are not, autosave was never the cause.

The daily auto-restart, and why it exists

On the Settings tab, the "Sleep, wake and schedule" group's "Automatic schedule" section has a "Daily auto-restart" row: an on/off switch plus a time select with one option per hour of the day, rendered as the hour followed by :00. Times are Thai time — the container is pinned to Asia/Bangkok. A server whose owner has never touched this restarts daily at 05:00, and the image is given a five-minute in-game warning to announce first.

Being straight about where that default comes from: it is our operational choice, not a vendor recommendation. Pocketpair publishes no advice to restart a dedicated server periodically. What they have published is the opposite direction — patch notes that fix dedicated-server memory leaks, including a v0.5.3 note reading "Fixed a memory leak on dedicated servers". So treat the daily restart as cheap insurance against long-uptime drift on a game we do not control, not as a workaround for a live known bug.

The image's own behaviour is to skip the reboot when players are connected. That is upstream behaviour we configure but do not test, so do not plan a session around it.

Set or clear the daily restart to match your group

Pick an hour nobody in your group plays. If you would rather restart by hand — for a group that plays late, 05:00 can land mid-session — switch the row off and use the restart control yourself. Like every other Palworld setting, the change applies on the next restart.

RAM: what Pocketpair asks for, and what we sell

This is the section to read before spending an evening on knobs.

Pocketpair's own requirements page lists memory as 16 GB, adds "Recommended for larger than 32GB", and says of 8 GB only that it "is also bootable, but increases the possibility of server crashes due to out of memory".

Our floor for Palworld is 8 GB — sizes below it are disabled in the size picker, and the create wizard says so outright. That floor is our choice, made because small private groups genuinely run on it. It is not a number Pocketpair blesses. Our largest plan is 32 GB, which means the publisher's recommendation sits at the very top of what we sell and their "more than 32 GB" is above it.

What that means for you, plainly: on 8 GB, a Palworld world with a lot of captured Pals and a lot of base building will eventually hit its ceiling, and the symptom is a crash rather than a stutter. If your RAM graph shows OOM markers, stop tuning and size up. Why game servers run out of RAM covers the mechanism, and /pricing has the sizes and what each costs per hour.

The first boot takes as long as it takes

A brand-new Palworld server can take up to 20 minutes before it accepts players, and that is normal rather than a fault. SteamCMD installs a 12–15 GB dedicated server onto your world volume before the game can start, and the platform allows the full 20 minutes for it. A boot straight after a large Palworld patch can be slow for the same reason, because the update runs at boot.

If a server is still not up well past that, it is no longer a slow install — that is worth a support message rather than another restart.

Read next

• Palworld server hosting — the do-it-yourself install, and what running one at home costs
• Game server RAM — what OOM actually is, and how much you need
• Dashboard tour — reading the resource-usage charts in full
• Auto-sleep — why a sleeping server is not a slow one