FiveM server thread hitch warning: causes and fixes

Updated

Verified against FXServer build 35245 (recommended), 37150 (latest), checked on 7 October 2026. Sources

VerdictNot evidence of a DDoS by itself

It means one of the server’s own loops ran late; the causes owners report are scripts, network events, the CPU or the host, and the warning alone is not evidence of an attack.

FiveShield does not help with this

FiveShield does not help with the warning itself: a proxy changes nothing about how fast your server threads run.

A hitch warning means one of the server’s own loops ran late. server thread hitch warning: timer interval of %d milliseconds is printed when two ticks of the main loop were more than 150 milliseconds apart (network thread: 150, sync thread: 100). The number is that gap on your machine, not ping, and it does not say where the time went.

Heavy scripts, large network events and a weak or shared CPU are the causes owners report; OneSync load and a flood are our reasoning from the code. The two-minute check below separates them; the ranking is editorial, not a statistic.

Suspect a DDoS only when something outside the machine, such as your host’s attack notice or an inbound traffic graph, matches the minutes of the warnings. A flood that saturates your connection is mostly dropped upstream, before it reaches your machine, so the server may print little or nothing (our reasoning).

Messages you may see

  • server thread hitch warning: timer interval of %d milliseconds

    Server console; two main loop ticks were more than 150 ms apart

  • network thread hitch warning: timer interval of %d milliseconds

    Server console; two network loop ticks were more than 150 ms apart

  • sync thread hitch warning: timer interval of %d milliseconds

    Server console; two sync loop ticks were more than 100 ms apart

  • hitch warning: net frame time of %d milliseconds

    Server console; the fallback network thread, at 150 ms or more

What it actually means

FXServer runs three timer-driven loops (GameServer.cpp). svMain, scheduled every 50 milliseconds, runs the server frame: queued console commands, the check that drops clients that stopped responding, your resources’ ticks (ServerResources.cpp) and more. svNetwork (every 10 milliseconds) services network packets and the send queue. svSync (every 8 milliseconds) runs the OneSync game-state update when OneSync is on (ServerGameState.cpp).

Each loop remembers when its previous tick began and prints one line when the gap exceeds its limit: 150 milliseconds for svMain and svNetwork, 100 for svSync. hitch warning: net frame time of %d milliseconds comes from a fallback network thread, at 150 or more; the network layer in builds 35245 and 37150 does not use it, so there you would see the network thread line instead. The number is the measured gap: a healthy main loop measures about 50 and prints nothing. A line says that much time passed between two ticks, never why.

Whatever runs on a late loop waits with it. A few hundred milliseconds is far from a disconnect: the server’s network layer uses a hard 30 second timeout for a silent connection (GameServerNet.ENet.cpp), so our reading is that players feel lag or rubber banding, not a drop. Owners do report many players dropping together while network thread warnings print; the guide on connection timed out covers that case. A stall of tens of seconds has its own message: after 45 seconds the watchdog (ServerWatchdog.cpp) prints Loop svMain seems hung! (last checkin %d seconds ago), repeated with STILL after 90, plus a watchdog stack: line naming the resource and the tick or event.

Check this first (two minutes)

Five checks that separate a script problem from a machine problem, and both from the traffic case.

  1. Which thread printed the line?

    The word before thread hitch warning: server is the main loop, network the packet loop, sync the OneSync loop.

  2. When do the lines print?

    Compare the timestamps with your change log.

  3. Record a profile during a burst of lines

    Wait until it stops recording, then profiler view (on a server it prints a link to open in Chrome) or profiler saveJSON filename.json (load it in Chrome DevTools, Performance tab). The guide does not say which threads a capture covers, so a clean profile clears neither the network nor the sync loop.

    profiler record 500

  4. Is the whole machine busy, or only FXServer?

    On Linux, sar -u reads the whole machine: look at %steal, the time the virtual CPU waited while the hypervisor served another virtual processor. A value that climbs during the bursts points at the host (our reading). On Windows, Get-Counter -Counter '\Process(*)\% Processor Time' lists CPU use per process (counter names are localized on a non-English Windows; Get-Counter -ListSet * shows yours).

    sar -u 1 10

  5. Do players drop, and does your host show anything?

    Ask two players for the exact minute and check your host’s dashboard for it.

Causes, ranked

Start with the card your check pointed at. The last one needs evidence from outside the machine.

Ranked by what owners report most and how cheap each check is. That is an editorial order, not a statistic: nobody publishes a dataset of FiveM outage causes. Documented means official docs or the FXServer and txAdmin source. Owners report means forum threads and issue trackers. Our inference is our reasoning from documented facts, shown so you can check it.

  1. A heavy or looping resource on the main thread

    Documented

    The main loop runs your resources’ ticks inside each frame (GameServer.cpp, ServerResources.cpp); a resource that does too much in its tick stretches the frame past 150 milliseconds and everything else on that loop waits. The profiler guide shows a script found by its file and line. Forum replies often blame a specific script first.

    How to confirm

    Profile a burst (profiler record 500, then profiler view). Hovering an event in the resource tick shows its time, file and line. If the lines stop when you stop that resource on a test server, it is confirmed.

    What to do

    Fix or replace the resource: let loops wait between passes, stop walking every player or entity each frame, cache results, move heavy work out of the tick.

  2. Starting or restarting resources while players are online

    Our inference

    The main frame also runs queued console commands (GameServer.cpp), so starting a large resource happens inside a frame and can make the next tick late. Our reasoning; the documentation does not describe the cost of a resource start.

    How to confirm

    Match the timestamps with the moments you ran start, restart or ensure. A burst at boot is the same effect.

    What to do

    Restart heavy resources outside peak hours, in one scheduled batch.

  3. Large or frequent network events, on the network thread

    Owners report

    The network loop handles packets to and from players (GameServer.cpp). The documentation warns that a large TriggerClientEvent blocks the client’s network channel and can end in a timeout, and recommends latent events for large payloads. Owners report network thread warnings, with many players dropping together, tied to scripts that send events to every player (-1) in a loop or as one big sync, even as latent events; the documentation gives no size at which the thread falls behind.

    How to confirm

    On a client in developer mode, neteventlog true lists events with direction, name and size (developer commands need +set moo 31337 or a non-production update channel). The drop reason Server->client connection timed out. Pending commands: %d. continues with a Command list: of the queued events and their sizes.

    What to do

    Latent events are the documented route for large payloads (TriggerLatentClientEvent, TriggerLatentServerEvent), with a modest bps: it applies per target, so sending to -1 costs bps times the player count every second, and around 10 000 000 and above can cause problems of its own. Send events only to the players who need them, and not in tight loops.

  4. OneSync entity load, on the sync thread

    Our inference

    With OneSync on, the sync loop runs the game-state update (ServerGameState.cpp). We infer that more entities and players make each tick longer and so can make the loop late; the documentation gives no limits.

    How to confirm

    The lines say sync thread hitch warning, onesync is on or legacy, and they rise with players, vehicles or entity-heavy maps. With onesync off the sync tick returns at once, so such lines would point elsewhere.

    What to do

    One setting at a time. Prefer onesync on to legacy if your scripts allow it (documented as not recommended for performance), keep onesync_distanceCulling on, and try onesync_distanceCullVehicles true (default false; documented as able to improve performance by reducing vehicle sync frequency).

  5. A weak, oversold or shared machine, or a scheduled job

    Owners report

    If the virtual CPU waits while the hypervisor serves another machine, or another program takes the CPU, the loops’ timers fire late and the loop warns even when your scripts are fine. Owners report a VPS CPU fault that the provider fixed, and a fix by moving the voice server to a dedicated host; a backup or database job sharing the CPU is our reasoning.

    How to confirm

    Run sar -u 1 10 during a burst and on a quiet minute: a %steal that climbs during the bursts points at the host. Compare the clock times of the lines with cron jobs, backups and other services. On Windows, compare the per-process counters from the CPU step.

    What to do

    Send your host the timestamps (and the sar output on Linux), move other services and scheduled jobs away, or move to dedicated cores.

  6. A flood that reaches the machine and has to be processed

    Our inferenceThe DDoS case

    A flood can slow a loop only by using something on your machine: the process reads what arrives and answers HTTP requests and handshakes, and handling packets takes CPU time too. FiveM’s documentation describes token-bucket limiters for the HTTP endpoints and handshakes (such as http_info and http_players, 4 tokens per second, burst 10) but gives no figure for how much traffic makes a loop late, and it does not say whether a flood prints these lines. A flood that saturates your connection is mostly dropped upstream, before it reaches your machine (our reasoning).

    How to confirm

    Look outside the machine at the same minutes: your host’s attack log or notice, inbound packets per second, captured packets from scattered sources (commands below). Nothing outside agrees: not this cause.

    What to do

    If the evidence is there, ask your host what it filters, with the timestamps. For proxy-based HTTP floods there is sv_requestParanoia (0 to 3, HTTP endpoints only), covered in the Layer 7 article below. Attack sources are usually spoofed (OVHcloud’s guide), so banning the addresses you see is unlikely to help.

What a DDoS looks like here

A hitch warning is a symptom on your machine, so it points at an attack only when something outside the machine agrees.

What a DDoS looks like here

  • The lines start inside a window your host reports as an attack, or inbound traffic rises on its chart in the same minutes, and both stop together.
  • Received packets per second jump at those minutes against a quiet-day baseline, and a capture of the game port shows many scattered sources, far above your player count.

Evidence you can collect

  • Your host’s own record

    On OVHcloud, open Network > Network Security Dashboard: the scrubbing centre log lists Detection time, End time, Destination IP and Attack vectors. OVHcloud emails you when traffic is rerouted, and says an empty log means no suspected attacks targeted your public IP addresses, though its guide also says some attacks are too specific to be detected and cleaned automatically. Entries are kept 1 year, traffic charts 2 months. Elsewhere, ask support for the attack log for those exact minutes.

  • Received packets per second (Linux)

    Capture on a quiet day and during a burst: rxpck/s is packets received per second. A jump at the warning minutes is a reason to ask your host. A flat line means no flood reached this machine, but traffic dropped upstream does not show here: check your host’s chart too.

    sar -n DEV 1 10

  • Received packets per second (Windows)

    The same comparison in PowerShell, quiet day against burst; press Ctrl+C to stop. Counter names are localized: on a non-English Windows, Get-Counter -ListSet * shows yours.

    Get-Counter -Counter '\Network Interface(*)\Packets Received/sec' -Continuous

  • Who is sending

    May need root. Replace 30120 with the port in your endpoint_add_udp line and <iface> with your interface; it stops after 2000 packets. Read the source column (our reading): a few repeating player addresses are normal, thousands of different ones are not. Sources are often spoofed, so use them to judge the scale, never to ban.

    tcpdump -n -i <iface> -c 2000 'udp dst port 30120'

What it does not look like

  • Lines only at boot, after a resource start, at the same clock time daily, or growing with the player count.
  • A profile where one resource dominates the tick, or a %steal that stays high.
  • A quiet console. A flood that saturates your connection is mostly dropped upstream (our reasoning), so players who cannot connect while the console is quiet have a different symptom, covered elsewhere.

When protection is, and is not, the answer

A proxy or filtering service works on packets before they reach your server; a hitch warning is about what your server does with the time it has.

Protection is the answer when

  • Your host reports attack traffic, or your inbound packet graph jumps, at the same minutes as the lines, and they stop with the traffic. That is a network problem with a hitch symptom: see the guides on a host traffic-spike notice and on mass timeouts.

Protection is not the answer when

  • One resource dominates the profile, or the events come from your own scripts and players: that is legitimate traffic, and a proxy forwards it.
  • %steal is high or other services share the CPU: the timers are late on the machine itself.

What a FiveM DDoS attack looks like

Still stuck? What to post

Paste these, with every key and password from your server.cfg removed (sv_licenseKey included).

  • Ten console lines around a burst, with timestamps.
  • How often, whether it clusters at boot, at fixed times or at peak, and what you started, updated or restarted shortly before.
  • Your FXServer artifact build, onesync setting, sv_maxClients and players online.
  • The profile: a screenshot of the resource tick, or the profiler saveJSON filename.json file.
  • The sar -u 1 10 output during a burst, and your hosting plan.
  • If you suspect an attack: the host’s notice or log entry with its times, and sar -n DEV 1 10 from a quiet minute and a burst.

Frequently asked questions

Is a hitch warning always a sign of a DDoS?

No. A loop prints the line when two of its ticks were more than 150 milliseconds apart (100 for sync). FiveM’s documentation does not say whether a flood produces it, or how much traffic that would take. The test is evidence from outside the machine: your host’s attack log or an inbound chart at the same minutes.

What is the difference between server, network and sync thread warnings?

server is the main loop (resources, timeout check, console commands; every 50 milliseconds, warns above 150), network the packet loop (every 10, above 150) and sync the OneSync loop (every 8, above 100). The one that prints tells you where to look first.

How do I find the resource behind a hitch warning?

Run profiler record 500 in the server console during a burst, then profiler view (on a server it prints a link to open in Chrome) or profiler saveJSON filename.json and load the capture in Chrome. resmon is a client command that needs developer mode and shows the client’s resources, not a server hitch.

Verified against, and sources

Verified against FXServer build 35245 (recommended), 37150 (latest), checked on 7 October 2026.

Server behaviour changes between builds. If your build prints something different, the build numbers above tell you what this page was checked against.