Evolution Host Logo

Evolution Host
Invent the Future

Diagnosis first

FiveM Server Troubleshooting Guide: Fix Lag, Hitch Warnings, Timeouts and Slow Downloads

When a FiveM server feels sluggish, the first job is not tuning random settings. It is identifying whether you are dealing with server-side load, network instability, static file delivery or a hosting problem.

Reading time ~10 minutes
Last updated
Category FiveM Troubleshooting

Start here

Quick diagnosis / symptom mapping

Use the symptom first, not the guess. That usually gets you to the real layer faster.

Fast separation rules

  • Join phase only = file delivery or reachability, not normal in-game lag.
  • One interior or district = streaming hotspot or client FPS first.
  • One ISP or one region = routing, local network or route quality first.
  • Started right after a change = treat the last change as your lead.

Do not jump to the wrong fix

Slow downloads do not need the optimisation workflow. Hitch warnings do not automatically mean you need a CDN. Timeouts do not automatically mean you are under attack. This page is here to separate those paths before you spend time or money in the wrong place.

Console symptom

Thread hitch warnings

Usually server-side

A thread hitch warning is a timing symptom. It means a server thread did not finish its work quickly enough. The warning is not the root cause. It is the sign that something underneath it needs attention.

What is causing the problem

Most of the time, a hitch warning comes from CPU-heavy resources, blocking database, file/network calls or bursty entity and event work that lands all at once during joins or peak activity.

What it usually points to

Repeated hitches that line up with one job, one script, one event or player peaks usually point to server-side work. Hitches with no unusual inbound traffic are not enough on their own to call the issue a DDoS attack.

Where to go next

Capture a profiler run while the warning is happening, then follow the deeper fix path on the FiveM Optimization page. If traffic spikes or route loss are part of the pattern, investigate the network separately before changing scripts.

thread hitch warning: timer interval of 157ms
profiler record 500
profiler status
profiler view

What makes the capture useful

Record during the bad window, not after it passes. One isolated spike is worth less than repeated bursts that match player complaints.

Common mistake

Chasing the warning itself instead of the work beneath it. The warning tells you that something was late. The profiler tells you what it was.

Player-facing symptom

Lag and poor performance

Split server lag from client FPS

Players call almost everything lag. The useful distinction is where it happens, when it happens and whether the player is actually seeing low FPS instead of server delay.

What is causing the problem

Server tick delay, entity and streaming hotspots, dense interiors, client rendering load and long-uptime buildup can all look similar from the player side.

What it usually points to

Peak-only lag points to scaling issues. One-zone lag points to a hotspot, not a full server problem. If ping and packet loss stay fine while FPS collapses, you are not debugging the same thing as server hitching.

Where to go next

Separate global server delay from local FPS first, then use the FiveM Optimization page for script, streaming and entity fixes. If the underlying resource picture looks clean, then review the hardware and route.

When it happens What it usually points to Where to go next
Only at player peak Scripts, sync or entity load that scales badly under population Profile and optimise resources first
Only in one area or interior Streaming hotspot, dense MLO, local entity load or client FPS Audit the hotspot area
Only after long uptime Buildup over time, stale state or resource drift Check cleanup, state and long-uptime behaviour
During connection Players are far from the server, the route is overloaded or slow Review the delivery path
Only a few players complain Route quality, local network or client-side performance Check route quality or the affected client

Use cl_drawperf before guessing

If cl_drawperf true shows FPS collapsing while ping and packet loss stay steady, you are solving client performance or streamed content, not server tick lag.

Use resmon before moving hosts

The client resource monitor is a quick way to confirm whether a local resource is hitting the player harder than the server. A vague feeling of lag is not enough to justify a host move.

Connection symptom

Player timeouts and packet loss

Network or severe server stalls

Timeouts are where server problems and network problems get mixed together most often. Packet loss, unstable routing, DDoS traffic or a badly stalled server can all end in the same player complaint.

What is causing the problem

Unstable routing, local ISP issues, attack traffic, congested upstreams or server threads that stall long enough to stop processing network work can all produce disconnects and red packet loss.

What it usually points to

One player or one ISP usually points to route or local network trouble. Whole waves of timeouts with traffic spikes point to network trouble or attack traffic. Whole waves during hitch storms but without unusual traffic point back to server-side stalls.

Where to go next

Have affected players use netgraph true and, if needed, net_statsFile. Use status on the server to compare pings. If the evidence points to route quality or attacks, go to the FiveM DDoS Protection page. If it lines up with hitch storms instead, treat it as a server-side stall first.

netgraph true
net_statsFile metrics.csv
status

Patterns that matter

  • One player only = local machine, Wi-Fi, ISP or route.
  • One ISP or one region = path quality between that region and the server.
  • Many players plus traffic spike = network event, attack traffic or upstream saturation.
  • Many players plus hitch storm = server-side stalls causing network symptoms.

Why this gets misread

A badly stalled server can create disconnects that look like network loss. Network trouble can also look like script lag. Use both server evidence and client network data before picking a fix path.

Join-time symptom

Slow downloads / stuck connecting

Usually file delivery

If joining is slow but gameplay is fine once the player is in, you are usually looking at the static file delivery path, not the live gameplay sync path.

What is causing the problem

Large asset packs, a weak file delivery path, stale proxy cache or a badly placed download endpoint can make joining crawl even when the game server itself is stable.

What it usually points to

If the player finally loads in and gameplay feels normal, the bottleneck is usually downloads. If info.json and direct connect fail externally, it is reachability or firewall, not CDN. If the problem started right after asset changes behind a proxy, stale cache is a prime suspect.

Where to go next

Move to the FiveM CDN page for the full fileserver and caching workflow. Keep this separate from gameplay tuning, because join-time delivery problems and in-game performance problems are not the same thing.

If direct connect and info.json fail

Fix reachability first. A CDN will not solve a closed port, bad firewall rule or a public endpoint that is not reachable from outside.

If the download bar crawls but gameplay is fine later

That usually points to oversized assets, distance to the file server, poor caching or a constrained resource delivery path.

If it began after proxy or asset changes

Assume stale cache or broken asset versioning before touching gameplay settings. Handle the detailed proxy and cache flow on the FiveM CDN page.

FiveM supports a separate file server path for resource downloads, which is why join-time slowness can be a delivery issue even when in-game sync is fine.

Boot and reachability

Server not starting / startup issues

Usually config, path or reachability

Startup problems are usually less mysterious than they feel. Most are launch path, config, reachability or one broken resource.

What is causing the problem

Missing or wrong sv_licenseKey, a bad working directory, missing +exec, broken resources, reachability problems or first-run setup issues with txAdmin are the usual suspects.

What it usually points to

No resources found usually means the launch path is wrong. Boots locally but invisible publicly usually means firewall, NAT, ports or public reachability. Very slow boots often mean antivirus scanning or a resource set that has grown too large.

Where to go next

Use the basic boot and reachability checks here first. If the environment itself is still getting in the way after you rule out config mistakes, move on to the infrastructure layer rather than changing gameplay settings.

FXServer.exe +exec server.cfg
bash ~/FXServer/server/run.sh +exec server.cfg
connect IP:30120
http://IP:30120/info.json

What to check first

  • No resources found or failed start resource usually means the working directory or resource itself is wrong.
  • No license key specified usually means the key is missing, the wrong config was loaded or the launch path is wrong.
  • If txAdmin is being set up for the first time, start FXServer in monitor mode instead of forcing +exec on that first run.

Reachability and listing

If the server runs locally but is missing from the browser or unreachable from outside, test direct connect, check info.json, confirm endpoint_add_tcp and endpoint_add_udp, keep #sv_master1 "" commented unless you want a private listing and make sure sv_projectName and sv_projectDesc are set.

Slow boot on Windows

Microsoft Defender can slow FXServer startup by scanning the server files and a large resource set will make the same symptom worse.

Linux note

The official docs still describe the Linux build as a courtesy port. If you hit a strange native issue, compare against the standard Windows flow before you spend days debugging your resources.

Change-related symptom

Crashes after updates

Start with what changed

After an update, the right question is not “what random thing broke?” It is “what changed last?” Most post-update crashes are change-related until proven otherwise.

What is causing the problem

New artifacts, framework dependency mismatches, map or asset changes, enforced game build mismatches and old resources exposed by a newer artifact are the most common causes.

What it usually points to

If the crash started right after one change, start there. Area-specific crashes usually point to one resource or asset set. Browser EOS or EOL warnings point to outdated artifacts first, not mystery instability.

Where to go next

Roll back the last changed artifact, resource or content pack on staging and retest. If it turns out to be one script, one asset set or one map area, keep the investigation narrow before blaming the whole server.

If the artifact changed

Start with the last artifact or dependency change. Unsupported artifacts older than three months are not joinable from the server browser, so outdated binaries need to be ruled out early.

If DLC or map content changed

Check your game build and content compatibility. The enforced game build is a startup setting, so test changes with a real restart between each attempt.

If one action or area crashes

That is usually a resource, asset or map problem. Treat it as localised until a clean test proves otherwise.

Keep the rollback small. When artifacts, scripts and proxy rules all change in one maintenance window, the postmortem takes longer than it needs to.

Infrastructure check

When hosting is the problem

Only after you narrow the layer

Once profiler data is clean and the symptom still spans players, the box or the route becomes a fair suspect. This is where you stop blaming one script and start looking at CPU headroom, storage stalls, region choice and network quality.

What is causing the problem

At this point the issue is infrastructure, not content. Think weak single-thread performance, inconsistent routing, storage stalls, memory pressure or shared-node contention.

What it usually points to

Your profiler and resource behaviour look sane, but the machine still runs out of headroom or route quality is inconsistent across players. Fresh installs on the same node still feel rough.

Where to go next

Move to the FiveM Hosting page if you need stronger CPUs, cleaner storage or a closer region. Once the content layer has been ruled out, infrastructure is the next sensible place to improve.

Strong signs it is the host or route

  • Profiler looks clean, but ordinary population still produces hitches.
  • Multiple regions or ISPs see the same loss pattern.
  • A clean baseline still has slow boots or storage stalls.
  • The machine is short on CPU, RAM or I/O headroom even without one obvious bad resource.
  • Moving region, node or plan materially changes the symptom.

Strong signs it is still your stack

  • One feature, one event or one resource reliably triggers the issue.
  • Only one area or interior lags.
  • The problem started right after content, script or framework changes.
  • Downloads are slow but gameplay is fine once players load in.
  • Only a small set of players on one route complain.

Good troubleshooting narrows the layer first. Good conversions happen naturally once the layer is obvious.

Common questions

FAQ

These answers are short on purpose. The goal is to help you pick the right next page, not trap you in a giant troubleshooting loop.

Are thread hitch warnings always a DDoS sign?

No. They usually mean a server thread is late because of resource load, blocking I/O or sync bursts. Treat it as a network or attack issue only when the warnings line up with unusual traffic or route loss.

Why do players time out even when the server still looks online?

Because network path loss and severe server stalls can both break the flow of packets long enough to drop clients. Online status does not prove the server was responsive at the exact moment players disconnected.

Why are FiveM downloads slow when in-game ping is fine?

Because join-time downloads use the static file delivery path, not the same live gameplay sync path. That usually points to asset delivery, cache, proxy or CDN work rather than normal gameplay networking.

What should I check first if the server will not start?

License key, working directory, launch command, broken resources and external reachability. Use direct connect and info.json before changing other settings.

What is the first thing to do after crashes begin right after an update?

Identify the last change and roll that back on staging first. Most post-update crashes are change-related, not random host failures.

When should I move to better hosting?

After your profiler is clean or the evidence points to network, storage or CPU headroom rather than one bad resource. Move hosts when the layer is clearly infrastructure, not before.

Why is startup slower on Windows than expected?

Large resource sets add time and Microsoft Defender can slow FXServer startup by scanning the server files.

Is Linux fine for FiveM?

It can work, but the official docs still describe the Linux build as a courtesy port. If you hit an odd native issue, compare behaviour on a standard Windows setup before blaming your resources.

Need a cleaner baseline

Stop troubleshooting three layers at once

Run your FiveM server on fast CPUs, stable routing and always-on DDoS-aware infrastructure.

Low latency locations NVMe storage Reverse proxy caching Around the clock support