How to Find the FiveM Resource Causing Your Server Lag

Server lag is rarely the host. When players start complaining about rubber banding and gunfire feels off, the cause is almost always one resource pinning the server thread. The right tools find it within minutes, but only if you know which signal to read first. This guide walks through the four checks that turn "the server feels bad" into "this resource at this line is the problem."

How FiveM Lag Actually Works

FiveM lag is not one thing. There are three distinct problems that all feel the same to players, and confusing them costs hours.

Server thread time is how long the server spends processing one tick. A healthy server completes a tick in under 5 milliseconds. When that climbs above 8ms the server cannot keep up with player events, and everything stalls. This is what resmon and the profiler measure.

Network lag is unrelated to your scripts. It comes from your host's bandwidth, the player's connection, or routing problems between them. You see it as ping spikes that affect specific players, not the whole server.

Client FPS is your players' machines, not yours. A new map, a heavy MLO, or too many entities streaming in tanks client framerate even when your server thread is idle.

This post covers the first one: server thread hitches caused by individual resources. The two terms to know are resmon (the in-game performance monitor) and OneSync workload (the entity sync layer that scales with player count and active entities).

Why this matters: Diagnosing the wrong layer is the most common mistake. If your tick rate is steady but ping is spiking, you are chasing a network issue, not a resource issue.

Step 1: Read Resmon In-Game

Connect to your server as admin, open the F8 console, and run resmon. A panel appears showing every running resource and what it costs the server thread.

The columns that matter:

CPU msec - how many milliseconds the resource spent in the last tick. This is your primary signal.
Time - cumulative CPU time since the resource started. Useful for spotting long-term drift.
Streaming - how much data the resource is streaming to clients. High values here cause client FPS issues, not server hitches.

What counts as healthy:

Under 3ms per tick is fine. Most resources sit here.
3 to 8ms is a warning. Worth investigating but not urgent.
Over 8ms is the problem. One resource consuming this on every tick will hitch your server under any meaningful load.

Resmon shows a single moment. Watch it for a minute or two during peak hours, not when the server is empty. A resource that idles at 1ms with three players might jump to 12ms with sixty.

Why this matters: Resmon is the fastest way to spot a resource that is already misbehaving, but it only shows what is happening right now.

Step 2: Use the FiveM Profiler

When resmon points at a suspicious resource but you need to know exactly which function is slow, switch to the built-in profiler.

From your server console, run:

profiler record 5000

This records 5000 frames of server activity. You can pass any number; longer recordings catch more events but produce larger files.

When the recording finishes, save it:

profiler save profile.json

The file lands in your server's data directory. Open it in the FiveM profiler viewer with the profilerView command in the F8 console, or load the JSON directly into Chrome's DevTools Performance tab.

The flame graph shows every Lua call by duration. Wide bars are slow functions. Look for:

A single resource dominating one frame (your culprit).
Repeated short calls adding up - usually a tight loop or unbatched query.
Long flat sections during specific events like player join or vehicle spawn.

Run the profiler during peak hours, and during the specific scenario you suspect. Recording an empty server proves nothing.

Why this matters: Resmon tells you which resource. The profiler tells you which function inside that resource, which is what you actually need to fix it.

Step 3: Watch Tick Rate Over Time

Resmon and the profiler both capture a moment. They miss the resource that runs fine for six days and then degrades over a long restart cycle, or the script that hitches once an hour when a specific cron fires.

For that you need historical data. The FiveGateway dashboard tracks server thread time as a continuous metric, alongside player count and CPU usage, so you can see exactly when tick rate started slipping. The server statistics feature page covers the full set of charts and how the data is collected.

Use the tick rate chart to answer questions resmon cannot:

"When did this start?" - look for the day or hour the chart began climbing.
"Is it correlated with player count?" - overlay tick rate and concurrent players. If they rise together, you are hitting a OneSync ceiling, not a buggy resource.
"Did the last update make it worse?" - compare the last 24 hours against the previous week.

Why this matters: A regression that took two weeks to develop will never show up in a one-minute resmon snapshot. Trend data is how you catch slow leaks.

Step 4: Correlate Hitches with Events

You spot a hitch in the chart at 14:32. Now what? Without context it is just a spike. With structured logs you can pull every event from that minute and see exactly what triggered it.

A vehicle spawn, a money transaction, or a player joining are all events that hit specific resources. If your hitch lines up with a flood of one event type, you have your answer. Structured logging in FiveGateway gives every entry a category, a timestamp, and metadata, so you can filter to a one-minute window and read what the server was doing when the thread stalled. The logging feature page covers categories, fields, and how to send entries from Lua.

Pair this with the tick rate chart. When the chart spikes, jump to the logs at the same timestamp. Patterns that take weeks to find by reading raw console output show up in seconds.

Why this matters: A hitch without context is noise. Structured logs turn a timestamp into a story.

Common Culprits

Most resource lag traces back to a small set of patterns:

Unbatched database queries. A loop that fires one MySQL.query per player per tick will eat your thread. Batch reads with a single SQL statement, and never run synchronous queries inside a server tick.
OneSync overload. Too many synced entities (vehicles, peds, props) push OneSync past what your server can process. Watch the entity count alongside tick rate and prune abandoned vehicles aggressively.
Streamed ymaps loaded into memory. Large MLOs and custom maps load every asset on resource start, even when no player is near them. Split heavy maps and load assets lazily where you can.
Infinite loops in custom scripts. A while true do without a Wait(), or a Wait(0) running expensive logic, spikes your thread instantly. Profiler flame graphs make these obvious.
Lua GC pressure. Allocating tables and strings inside a tight server loop forces frequent garbage collection. Reuse tables, avoid string concatenation in hot paths, and prefer numeric keys over string keys for high-frequency data.

Run the profiler against the resource you suspect and look for the pattern. The fix is usually a few lines of Lua, not a rewrite.

Why this matters: The same handful of mistakes account for most resource lag. Recognizing them on sight saves hours of profiling.

When the Resource Is Not Yours

Paid resources from Tebex creators are common, and you cannot always edit them. When the profiler points at a script you did not write:

Capture proof before you contact the author. Save the profiler dump and a screenshot of resmon showing the offending resource at peak. A vague "your script is laggy" report goes nowhere; a JSON file showing exactly which function consumes 15ms gets attention.
Open an issue on the creator's support channel - usually Discord or a Tebex ticket. Include the profiler dump, your player count at the time, and the FiveM artifact version you are running.
Ask for a profiler dump from a known-good version if the resource was working before an update. This narrows the regression for the author.
Disable the resource temporarily if the lag is severe enough to affect your server. A bad update is not worth losing your player base over while you wait for a fix.

If the author is unresponsive and the resource is critical, your options are forking a maintained alternative or replacing it. Document the cost of leaving it broken and decide accordingly.

Why this matters: A profiler dump turns a support ticket from a complaint into a bug report the author can act on within minutes.

Stop Guessing, Start Measuring

Resmon and the profiler tell you what is wrong right now. The dashboard tells you when it started, what it correlates with, and whether your last fix actually worked. Combine all three and resource lag stops being a mystery.

Track tick rate, players, and CPU on every server you run →

Open the dashboard at my.fivegateway.com or compare plans on the pricing page.

Stay Updated

Follow development updates, feature announcements, and behind-the-scenes progress: