How to Use resmon in FiveM: Find Laggy Scripts Before They Kill Your Server
When a FiveM server lags, most owners blame the host or the framework. Sometimes that is true. But very often, one resource is doing something expensive and dragging everything down.
resmon is the fastest way to find that resource.
Table of Contents
- What resmon shows
- How to run it
- What “bad” looks like
- The safe way to fix the issue
- Keeping performance stable long-term
1. What resmon shows
resmon shows how much time each resource uses. If one resource constantly sits at the top, it is a strong suspect.
2. How to run it
Open your server console and run the resmon command. Then watch how resource usage changes when players do normal activities.
3. What “bad” looks like
The biggest red flag is a resource that spikes when nothing special is happening.
Another red flag is a resource that slowly gets worse over time.
4. The safe way to fix the issue
Do not delete random files.
Disable the suspected resource and test again.
If the server becomes stable, replace the resource or update it.
5. Keeping performance stable long-term
Performance is a routine, not a one-time fix.
If you want a broader stability guide, read /blog/why-your-fivem-server-keeps-crashing.
What resmon actually shows
resmon is the FiveM client-side resource monitor (open with F8 then type resmon). It shows per-resource:
- CPU msec - main-thread time used per frame.
- Memory - RAM used by the resource.
- Streaming - asset memory.
The number you care about most is CPU msec. The frame budget at 60 Hz is 16.6 ms; resources should sit at 0.1-0.4 ms idle, with brief spikes during events.
What "laggy" looks like in resmon
| CPU msec idle | Status |
|---|---|
| 0.0-0.2 | clean |
| 0.2-0.5 | normal for active resources |
| 0.5-1.0 | suspicious; investigate |
| 1.0-3.0 | causing visible stutter |
| 3.0+ | this resource is the lag |
A handful of resources at 1.0+ ms each pushes total tick to 8-10 ms, leaving no headroom for player-driven events.
Common offenders we've seen
| Resource pattern | Why it's expensive |
|---|---|
while true do ... end without Wait | runs every frame, kills CPU |
| Database query in a per-frame loop | one query per tick = MariaDB melts |
| GetEntityCoords on every player every frame | quadratic with player count |
| Drawing 3D markers every frame | each is a draw call |
| Polling instead of event-driven | watch for missing event handlers |
Profile a single resource
In server console:
profiler record 100
profiler view
Records 100 frames, opens a flame graph. The hottest functions are the lag.
Server-side resmon equivalent
profiler view (after record)
Plus the server txAdmin > Diagnostics > Performance graph.
Fixing the most common cause: missing Wait
-- BAD: runs every frame, ~16ms/s
CreateThread(function()
while true do
UpdatePlayerStats()
end
end)
-- GOOD: runs every 5 seconds
CreateThread(function()
while true do
UpdatePlayerStats()
Wait(5000)
end
end)
A single while true do end without Wait will pin one core to 100 % and add 5-15 ms to every frame.
Per-frame draw cost
-- BAD: draws marker every frame for every nearby ped
for _, ped in ipairs(GetGamePool('CPed')) do
DrawMarker(...)
end
-- BETTER: cap distance, cache the list, only draw when needed
When the lag is server-side, not client-side
If resmon shows nothing over 0.5 ms but the server feels laggy, the bottleneck is server-side. Run profiler on the server console; the hot resource will be different from any client measurement.
Workflow for fixing a slow server
- F8
resmonon a player client. Note any resource > 1.0 ms. - Disable that resource. Test again.
- If lag persists, server console
profiler record 200; profiler view. - Inspect the hottest function. Add Wait, cache, or replace with event-driven code.
- Repeat until no resource exceeds 0.5 ms idle.
A server that was at 8 ms tick can routinely come down to 2 ms after this loop.
