FiveM “server thread hitch warning”: what it means and how to fix it

A warning like “server thread hitch warning: timer interval of 250 milliseconds” means the server's main loop stalled for that long. Players feel it as rubber-banding, delayed actions and desync. Here is how to find the cause instead of guessing.

By the Nodewave team · Updated 8 November 2026

What the warning means

FXServer runs most game logic, including every server script, on one main thread. Each pass of that loop should take a few milliseconds. When one takes much longer, the console prints a hitch warning with the length of the stall. Similar warnings can name the network or sync thread.

• A few hitches while the server starts are normal: resources are loading and the database is warming up.
• Hitches that keep repeating during play mean something is wrong, and players will notice.

1. Find the resource with the profiler

FXServer has a built-in profiler. Run it in the server console (txAdmin's Live Console), not in the F8 console, while the hitches are happening:

profiler record 500
profiler status
profiler saveJSON hitch.json

profiler record 500 captures the next 500 frames. When profiler status shows the capture is done, save it, open Chrome's developer tools, go to the Performance tab and load the file. Hitches show up as tall spikes; zoom into one to see which resource took the time, down to the file and line.

2. Fix the usual causes in scripts

• Loops that run every tick. A server loop with Wait(0) runs as often as it can. Most server loops can wait hundreds or thousands of milliseconds between passes.
• Work on every player or entity at once. Looping over all players or vehicles every second gets expensive as the city grows. Spread the work out, or react to events instead of checking constantly.
• Slow database queries. A query that scans a big table without an index can take hundreds of milliseconds. oxmysql reports slow queries in the console; add indexes for the columns they search, and don't run queries inside tight loops.
• Event spam. Clients triggering server events many times a second, by mistake or by cheating, keep the main thread busy. Rate-limit expensive events.
• Old resources. Remove scripts you no longer use, and update the ones you do.

3. Check the database server

Roleplay servers write to the database constantly. Keep MariaDB on the same machine or very close to it, on NVMe storage, with enough memory. Clear out log tables that grow without limit, and back the database up regularly.

4. Check the host

• CPU speed. The main thread uses one core, so single-thread speed decides how much script work fits in each frame. A slow or overloaded host core turns small script costs into hitches.
• Antivirus on Windows servers. Real-time scanning of a big server folder can use a lot of CPU. On Windows servers we support, Microsoft Defender has used more CPU than FXServer itself. Exclude the server folder, FXServer.exe and the database program from scanning, and keep real-time protection on for everything else.
• Other programs on the same machine. Bots, web panels and backups that run at peak time compete for the same CPU.

Lag on only some players' screens?

Client lag is different from a server hitch. If only some players stutter, ask them to open the F8 console and run resmon 1 to see which resources use the most time on their side.

Keep it from coming back

• Profile after adding any big script, not weeks later.
• Watch your server's CPU graph during peak hours.
• Test updates on a copy of the server first.

Script errors in the console, such as “attempt to index a nil value”, are a different problem. See how to fix that error in ESX and QBCore scripts.