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 find the "Resource usage" card. At the bottom of it, Palworld servers get a "Game health" block with two lines: "Server FPS" and "Players online". 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 card's range tabs to "7d". A single evening tells you almost nothing; a week tells you which of the four shapes you have.
| What the two lines do together | What it usually means |
|---|
| FPS stays flat while players climb | The server is coping — the stutter your friends report is probably their connection, not the host |
| FPS falls as players join, recovers when they leave | You are CPU-bound at this player count |
| FPS dips in a regular rhythm regardless of players | The auto-save hitch — see the auto-save section below |
| FPS is fine after a restart and worse each day | An uptime problem — the daily restart section is yours |
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 markers only appear on the RAM and CPU graphs — the dashboard tour explains how to read them.
In the "Palworld settings" card there is a switch labelled "Engine performance boost (Server FPS)". 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.
Nothing in that card touches a running server. Save, then restart from the server's own controls — the card says so itself, and it 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 "Server FPS" line 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
Under "In-Game Settings" in the same card, the "Other" group holds "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
The same card has a "Daily auto-restart" dropdown: "Off", plus 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 — set it to "Off" and use the restart control yourself. Like everything else in this card, 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. covers the mechanism, and 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
- — the do-it-yourself install, and what running one at home costs
- — what OOM actually is, and how much you need
- — reading the resource-usage card in full
- — why a sleeping server is not a slow one