How do I fix FiveM server lag and 'server thread hitch warning'?

Keep seeing server thread hitch warning: timer interval of XXX milliseconds in your FiveM server console while players complain about lag and rubber banding? That message means the server thread is falling behind. This guide explains what the warning means, how to find heavy resources with resmon and how to fix the four biggest culprits.

What does 'server thread hitch warning' mean?

FXServer runs the core of your server — player synchronisation, events and most of your script logic — on a single main thread (svMain). That thread works in short ticks. When one tick takes far longer than planned, say 250 milliseconds instead of a few, the server logs a hitch warning with the measured time. During such a stall everything freezes: players snap back, vehicles hang in place and events arrive late.

Because all this work happens on one thread, the single-thread speed of the CPU is decisive — not the number of cores and not the amount of RAM. In practice, however, the cause is usually not slow hardware but one resource hogging the thread. This article is specific to FiveM; lag on a Minecraft server works very differently and has its own optimisation article.

Step 1: Find heavy resources with resmon

1. Connect to your server, open the client console with F8 and type resmon 1. The resource monitor window appears.
2. Watch the CPU msec column: this is how many milliseconds a resource costs per frame. Leave the window open while you play.
3. Interpret the values: a well-behaved resource stays below 0.10 ms. A script that sits above 1.00 ms all the time is heavy; spikes of several milliseconds point straight at the culprit.
4. Resmon measures your client. To profile the server thread itself, use the Console tab in the MC-Node panel: type profiler record 500, then profiler view. The link it prints shows per resource which functions are holding up the tick; in txAdmin the dashboard graphs also show tick times.
5. No obvious spike? Temporarily stop suspect resources with stop resourcename in the console and check whether the warnings disappear. Rule out half of them at a time to find the culprit.

Step 2: Fix the four biggest culprits

1. Scripts with tight loops — A loop like while true do ... Citizen.Wait(0) end runs every single tick, even when there is nothing to do. Raise the wait to something like Citizen.Wait(1000) for checks that do not need to run constantly, and make code react to events instead of polling. If an encrypted (escrow) or abandoned script stays heavy, replacing it with a maintained alternative is almost always the better choice.
2. Oversized vehicle textures (YTD) — Addon cars with 4K or 8K textures eat streaming memory: players get stutters, texture loss and long download times. Resize textures to 2K at most, remove unused livery variants and be critical of packs weighing hundreds of megabytes. See the addon vehicle guide for installing cars in a lightweight way.
3. Blocking database queries — A synchronous query stalls the server thread until the database answers. Use an up-to-date async wrapper such as oxmysql, replace outdated mysql-async scripts and add indexes to frequently used tables such as users and owned_vehicles. Save player data in batches instead of on every small change. You will find your database credentials under the Databases tab.
4. Too many entities — Every spawned vehicle, prop and ped has to be synchronised each tick; thousands of abandoned cars make that noticeably more expensive. Run a cleanup script that removes empty vehicles after a few minutes, limit spawner scripts and watch out for maps that place huge numbers of props — see the MLO and custom map guide.

When is the hardware really the bottleneck?

The classic trap is blaming the host while one script eats 90% of the frame time — the profiler exposes that mercilessly. But the opposite exists too. Is resmon clean, does the profiler spread the tick time evenly across many small tasks without one clear spike, and do the warnings only appear at high player counts? Then you are hitting the single-thread limit of the CPU. More RAM or extra slots will not fix that; only hardware with a higher clock speed per core still helps.

Common messages and situations

• Hitch warnings during startup — During a (re)start the server loads all resources at once; a few warnings are normal. Only messages that keep coming back during gameplay are a problem.
• sync thread hitch warning or network thread hitch warning — These variants usually point at the synchronisation layer: too many entities or players. Clean up entities (step 2, point 4) and check that OneSync Infinity is enabled.
• Hitches at fixed times — If the stutter returns exactly every five or ten minutes, a periodic task is almost always to blame: a save loop writing all players at once, or a backup during peak hours. Spread out saving in your scripts and schedule backups at night via the Schedules and Backups tabs.
• Rubber banding without hitch warnings in the console — Then the problem is most likely on the client side or the player's network. Ask affected players to check their own fps and resmon; oversized YTDs are a frequent cause.
• The warnings persist after all steps — Record a profiler capture with profiler record 500 right after a stutter and keep the output; it makes the cause much easier to trace.

Need help?

With resmon and the profiler you can find almost any cause of server lag within minutes. If you get stuck, open a ticket via our support page and include the exact message from the Console tab plus your resmon or profiler findings.