Evolution Host
Invent the Future
Diagnosis first
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.
Start here
Use the symptom first, not the guess. That usually gets you to the real layer faster.
A server thread is late. Think resource load, blocking I/O or sync bursts first.
Open the hitch warning pathPlayers say the server feels bad, but you still need to separate tick delay from local FPS.
Split lag by time, place & scopePlayers drop, freeze or report red packet loss. Decide whether the route is bad or the server is stalling.
Read the timeout pathJoining is painful but once in, gameplay can be fine. That usually means file delivery.
Check the join-time pathFXServer will not boot, resources do not load or the server runs locally but stays unreachable.
Run the startup checksThe problem began after an artifact, map, framework or content change. Treat the last change as the lead.
Start with what changedSlow 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
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.
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.
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.
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 viewRecord during the bad window, not after it passes. One isolated spike is worth less than repeated bursts that match player complaints.
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
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.
Server tick delay, entity and streaming hotspots, dense interiors, client rendering load and long-uptime buildup can all look similar from the player side.
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.
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 |
cl_drawperf before guessingIf 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.
resmon before moving hostsThe 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
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.
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.
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.
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
statusA 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
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.
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.
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.
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.
info.json failFix reachability first. A CDN will not solve a closed port, bad firewall rule or a public endpoint that is not reachable from outside.
That usually points to oversized assets, distance to the file server, poor caching or a constrained resource delivery path.
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
Startup problems are usually less mysterious than they feel. Most are launch path, config, reachability or one broken resource.
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.
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.
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+exec on that first run.
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.
Microsoft Defender can slow FXServer startup by scanning the server files and a large resource set will make the same symptom worse.
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
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.
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.
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.
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.
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.
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.
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
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.
At this point the issue is infrastructure, not content. Think weak single-thread performance, inconsistent routing, storage stalls, memory pressure or shared-node contention.
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.
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.
Good troubleshooting narrows the layer first. Good conversions happen naturally once the layer is obvious.
Common questions
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.
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.
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.
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.
License key, working directory, launch command, broken resources and external reachability. Use direct connect and info.json before changing other settings.
Identify the last change and roll that back on staging first. Most post-update crashes are change-related, not random host failures.
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.
Large resource sets add time and Microsoft Defender can slow FXServer startup by scanning the server files.
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
Run your FiveM server on fast CPUs, stable routing and always-on DDoS-aware infrastructure.