When a FiveM server lags, the instinct is to blame the host and buy a bigger plan. Lag can come from a resource, a database path, streamed assets, the host, or the reproduction case. Use the tools you already have to separate them before changing the plan.

Profile the same reproducible scenario before and after each change. Keep client Resmon readings separate from server profiler and txAdmin evidence so you investigate the system that shows the symptom.

First, understand what is lagging

Rubber-banding, delayed menus, or input delay can involve server work, resources, database behavior, the host, network conditions, or the client. Aggregate CPU alone does not distinguish those cases. Reproduce the same scenario and compare the relevant readings. Record whether the symptom appears in client resource usage, server hitches or both before choosing the next diagnostic step.

A reproducible diagnosis

  1. Open txAdmin and look at the server dashboard. Note the thread tick time and the hitch graph. Compare the readings with the reproduction case; they support a server-side hypothesis but do not exclude client or network factors on their own.
  2. Connect to your own server in-game, press F8 to open the client console, and run resmon true to inspect client resources. This developer command requires client developer mode. If access is denied, follow the Cfx.re developer-mode instructions, which document launching the client with +set moo 31337.
  3. Sort by CPU time, reproduce the symptom, and note which resources change with it. Those are candidates for investigation, not proof by threshold alone.
  4. For server hitches, open the server console and run profiler record 500 while reproducing the issue. Check profiler status, then use profiler view when recording finishes. Open the returned link in Chrome to inspect the capture. The Cfx.re profiler guide explains how to trace recorded resource work. Compare it with txAdmin; client Resmon readings alone do not identify server-side resource cost.

Example: a menu freezes when you open it

Use this as a test procedure, not a reported FiveMCoach benchmark. Work on a test copy with the relevant resource and its dependencies. Record the server artifact, game build, resource versions, client settings and connected test-player count before capturing anything.

  1. Stand in one chosen location and wait for startup activity to finish. Record a control capture without opening the menu, then another while opening it. Note the time of the freeze and whether other players also saw a delay. Keep the action, location and settings unchanged.
  2. If the issue is visible on the client, inspect client Resmon and record a profiler capture from F8. If server hitches occur at the same time, record from the server console too. Both consoles support profiler record 500; these are 500 frames, not 500 seconds. A short capture that misses the freeze does not clear the resource.
  3. After profiler status reports completion, save the control and symptom captures with different names, for example profiler saveJSON menu-control.json and profiler saveJSON menu-open.json. Keep the running client or server open while using profiler view; the profiler documentation also explains loading a saved capture.
  4. Inspect work around the freeze, choose one supported hypothesis, and change only that variable on the test copy. Repeat the same captures and player action. Keep a change only when the target symptom improves without breaking the menu or its saved state. Record inconclusive results and restore the previous version when the change does not help.

A useful record contains: reproduction steps, versions, control capture, symptom capture, proposed cause, single change, repeated result and rollback decision. Capture length and a resource's displayed milliseconds are context for diagnosis, not a universal player-capacity rating. If you also have a script error, paste a sanitized excerpt into the error decoder and use the debugging lesson to investigate the named file and line.

Patterns to check

1. Unoptimized script loops

One pattern is a resource doing more work per tick than it needs to. Examples include heavy logic inside a tight while true do ... Wait(0) loop, repeated native calls, or iterating across players more often than the behavior requires. Change timing or caching only after confirming the required behavior and measuring the same scenario; a longer wait is not automatically safe.

2. Database queries on a hot path

Database calling patterns matter. Check for repeated queries on a reproduced hot path, long-running statements, or lookups whose query plan scans more data than expected. Capture the query and plan first; apply caching, batching, async calls, or indexes only when the trace supports that change and correctness is preserved. The recorded query timings and execution plans should identify the work worth investigating before changing configuration or adding indexes.

3. Resource startup spikes

Profile startup separately from steady-state operation. Record which resources start, their dependencies, the observed hitch window, and whether the symptom persists after initialization. A restart-time reading does not establish the cause of a later steady-state issue.

4. Entity-density hotspots

If the symptom reproduces only in a location with many entities, compare entity counts, relevant resources, and sync behavior inside and outside that location. Test one scoped change, such as zone activation or an entity cap, and keep it only when the same reproduction evidence improves.

5. Streamed asset pressure

Streamed assets are one client, memory, and download hypothesis. Audit your stream folders, file sizes, observed client behavior, and actual use before removing or replacing an asset. Do not infer a server-tick cause from asset size alone.

Changes that need evidence first

  • Upgrading to more CPU cores. Do not assume aggregate core count resolves the measured execution-path bottleneck.
  • Adding RAM when you were not actually out of memory.
  • Switching operating system without a reproduced operating-system-specific constraint.
  • Removing shared libraries like ox_lib or ox_inventory without a profile that identifies them. Measure before you blame a dependency.

If the captured work shows a constrained execution path, compare a hardware change against the same workload. Record the configuration, timings and player-visible symptom before and after; a core count or advertised player limit alone does not validate the change.

When to get help

If you have worked the checklist and still cannot identify the bottleneck, a structured review can document the measured candidates and their fix order. A Server X-Ray Audit returns a prioritized written list of what to investigate first.

Frequently asked questions