When a FiveM server starts lagging, the first reaction is often to blame the host.
Sometimes the host is the problem.
Very often, the real problem is one resource doing far more work than expected.
A bad loop, an expensive SQL query, too many entities or one script that scales poorly with player count can turn a server that feels perfect at 40 players into a mess at 200.
The good news is that FiveM already gives you tools to narrow the problem down.
What are hitch warnings?
Cfx.re describes hitch warnings as a sign that one of your resources is not performing as it should.
The cause can include slow SQL queries, unoptimized loops or code that blocks script execution for too long.
Official reference: Cfx.re Performance Fact Sheet
One hitch warning does not automatically identify the guilty resource.
Think of it as a symptom.
The next step is to capture what the server was doing when the hitch occurred.
Start by reproducing the problem
Performance work is much easier when you can reproduce the issue.
Write down:
- approximate player count
- time of day
- what players were doing
- whether an event was active
- whether a restart recently happened
- whether a new resource was deployed
- whether the database was under load
- whether the issue is client-side, server-side or both
“Server feels laggy” is difficult to investigate.
“Server hitches every time 120+ players finish the same job event” is much easier.
Use Resource Monitor for client-side resource cost
FiveM's Resource Monitor can show CPU time and memory use for client resources.
The Cfx.re documentation lists the resmon command as the built-in resource monitor.
Official reference: Console Commands
A resource showing high usage deserves investigation, but avoid reading one number without context.
Some resources are expensive only while their UI is open. Others spike during loading. Some perform work in bursts.
Watch behavior over time.
What does a bad resmon pattern look like?
The most suspicious patterns are usually not one tiny spike.
Look for:
- a resource that stays expensive while idle
- usage that increases as more entities appear
- a UI resource consuming time while closed
- loops that remain active everywhere on the map
- a resource whose cost grows after every reconnect
- memory use that keeps climbing
- several resources repeatedly calling each other
Use the profiler when resmon is not enough
The FiveM profiler is designed to help identify code paths and threads that are taking too long.
Cfx.re's profiler guide documents commands such as:
profiler record 500
and the workflow for viewing captured performance data.
Official guide: Using the Profiler
The profiler is especially useful when you know which resource is expensive but not why.
Instead of only seeing that my_resource is slow, you can investigate which function, thread or repeated code path is consuming time.
Profile the correct moment
A profile captured while the server is idle may tell you nothing about the actual incident.
Record during the behavior you are investigating.
Examples:
- opening a large inventory
- loading a character
- spawning a vehicle
- completing a job
- entering a dense area
- 100 players reconnecting after restart
- running a scheduled save
- restarting one dependency
Performance debugging is about capturing the bad state, not collecting random data.
Check server-side SQL
Many serious hitches come from database work.
Common mistakes include:
SELECT * FROM huge_table
when the script needs one row, missing indexes on frequently searched columns, or writing data far more often than necessary.
A query that takes 15 ms in an empty development database can behave very differently after a year of production data.
Watch for resources that:
- query on every tick
- query once per player inside loops
- repeatedly fetch data that could be cached
- perform large synchronous workflows
- create N+1 query patterns
- write unchanged state repeatedly
The database is part of your game loop whether the players can see it or not.
Look for loops that never sleep
Lua scripts frequently use loops.
The problem is not that loops exist. The problem is work being done far more often than necessary.
A loop checking something every frame for every player can become expensive very quickly.
Ask whether the code really needs:
- every frame
- every 100 ms
- every second
- only when the player enters a state
- only after an event
Event-driven code is often cleaner than constant polling when the underlying state does not change continuously.
Distance checks can become expensive
A common pattern is repeatedly calculating distance from the player to many locations.
That may be fine for 10 points.
It becomes less attractive when the resource scans hundreds of locations every frame.
Better designs narrow the candidate set first or reduce check frequency when the player is far away.
The exact optimization depends on the resource, but the general rule is simple:
Do not do expensive work at high frequency when the result cannot meaningfully change that fast.
Watch entity-heavy scripts
Vehicles, peds and objects can create both client and server cost.
A resource that fails to clean up entities can become progressively worse over time.
That creates a classic symptom:
The server feels fine after restart, then gets worse several hours later.
If performance degrades with uptime, inspect resources that spawn or manage large numbers of entities.
Separate network lag from script lag
Not every bad player experience is script CPU.
Players may describe all of these as “lag”:
- low FPS
- high ping
- packet loss
- server hitching
- entity sync delay
- slow database responses
- NUI freezing
- texture streaming issues
Measure the problem before optimizing the wrong layer.
FiveM provides tools such as netgraph for network inspection and Resource Monitor for client resource cost.
Compare performance with player count
This is where historical monitoring helps.
If hitches only appear during your busiest hours, compare technical incidents with the server's player history.
Fexmetrics can show when the server normally reaches its peak population and whether downtime or abnormal drops line up with those periods.
Browse your server through Fexmetrics Servers.
This does not replace profiling. It gives the profiling result operating context.
Test by disabling one resource carefully
When you strongly suspect one resource, a controlled test can be useful.
FiveM provides resource commands including:
stop resource_name
start resource_name
restart resource_name
ensure resource_name
Official reference: Server Commands
Do not randomly stop production dependencies while hundreds of players are connected.
Test in staging when possible, especially for framework-level resources.
Build a performance baseline
The best time to measure performance is before something breaks.
Keep a baseline for:
- idle server CPU
- normal peak CPU
- memory
- database latency
- average player count
- typical peak count
- restart recovery time
- major resource costs
Then when a new script is added, compare against that baseline.
Without a baseline, every incident starts with guessing.
A repeatable FiveM performance workflow
When players report lag:
- Confirm whether it is client, network or server-side.
- Record the player count and exact behavior.
- Check recent resource changes.
- Use resmon for client resource cost.
- Capture a profiler trace during the bad state.
- Inspect SQL and server logs.
- Check entity-heavy resources.
- Reproduce in staging.
- Change one thing at a time.
- Measure again.
Final takeaway
You do not fix FiveM lag by blindly deleting scripts.
You fix it by identifying which layer is slow and measuring the code while the problem is happening.
Resmon tells you where client resource time is going. The profiler helps you inspect deeper execution. Logs and database metrics explain server-side work. Player history tells you whether the problem scales with activity.
Once those pieces are together, “the server is lagging” becomes an actual engineering problem you can solve.