When a FiveM server feels unstable, owners often blame the framework or the scripts. The first pass should be simpler: read the server.cfg and the startup log. Most common issues are visible in under ten minutes if you know what to look for.
Load order: framework and dependencies first
Resources that depend on a framework or shared library must start after that dependency is fully loaded. A common mistake is placing ox_lib, oxmysql, or a framework resource after the scripts that require it, which produces silent errors or broken callbacks. The correct sequence is: database driver, ox_lib, framework core, then everything else.
# Correct load order
ensure oxmysql
ensure ox_lib
ensure es_extended # or qb-core / qbx_core
ensure ox_inventory
ensure ox_target
# ... other scripts belowDuplicate starts and stale resources
Duplicate ensure lines for the same resource cause that resource to initialize twice, which can corrupt shared state, register event handlers twice, and produce hard-to-diagnose conflicts. Old tutorial packs and abandoned script folders that are still referenced in server.cfg add startup time, use tick budget, and occasionally register conflicting event names. Remove or comment out everyensure line that points to something no longer in use.
# Bad: duplicate and stale ensures
ensure qs-inventory
ensure qs-inventory # removes on the second start
ensure old-esx-drugs # abandoned, still startsOneSync, sv_maxclients, and slot sizing
OneSync must be enabled for any server running more than 32 players. Set onesync on (legacy) or onesync_enabled 1depending on your artifact version; on recent artifacts the recommended value is onesync on. Match sv_maxclients to your actual VPS capacity: overpromising slots you cannot sustain at full population degrades TPS for all connected players. Most servers on a 4-vCPU VPS should cap between 32 and 64 until the script stack is profiled.
sv_maxclients 64
onesync onDatabase connection and artifact compatibility
The oxmysql (or mysql-async) connection string must point to a running database accessible from the VPS, with the correct charset. FiveM and most modern frameworks expect utf8mb4; using a narrower charset can corrupt names, item labels, and chat that contain emoji or non-Latin characters. If oxmysql fails to connect, the server will start but every database-dependent script will silently fail, players spawn with no inventory, no money, and no character, while the console shows connection errors most owners scroll past.
set mysql_connection_string "mysql://user:[email protected]/fivem?charset=utf8mb4"Artifact (FXServer build) currency matters more than most owners realize. New scripting-runtime features, OneSync fixes, and security patches ship in newer artifacts, and current ox_lib, oxmysql, and framework versions increasingly assume a recent build. Running a years-old artifact is one of the most common reasons a freshly downloaded resource refuses to start. Pull builds from the official Cfx.re artifacts page, prefer a recommended (stable) build over the bleeding-edge latest, and re-test your stack on a staging server before promoting a new artifact to production. Updating the artifact is a five-minute job that prevents a category of "it works for everyone else" bugs.
oxmysql: where database cost actually hides
A database call is not free, and the cost shows up on the server tick when queries are written carelessly. Three patterns cause most of the damage. First, queries inside a per-tick loop: a script that reads or writes the database every frame instead of caching the value will generate thousands of round trips a minute. Second, synchronous queries on a hot path, the older MySQL.Sync style blocks the calling thread until the database answers, so one slow query stalls everything behind it. Prefer the promise or await-style oxmysql API so the server keeps ticking while the query resolves. Third, unindexed lookups: a SELECT ... WHERE identifier = ? against a table with no index on identifier forces a full scan that gets slower as the table grows, which is why a server feels fine in week one and sluggish in month three.
You do not have to guess which queries are expensive. oxmysql can log slow queries: set its debug or slow-query convar and watch the console under real load. Anything that consistently shows up as slow is a candidate for an index or a rewrite. For the SQL indexing and hot-path treatment in detail, see the FiveM Coach by Quasar server optimization guide.
OneSync population, scripting, and bubbles
OneSync is more than an on/off switch. Beyond enabling it for servers over 32 slots, the OneSync convars control how the server populates the world and how much it has to track. Higher entity and population settings make the world feel fuller but increase the server's per-tick synchronization workload, which is real CPU on the single-threaded main loop. If your server is fighting for tick budget, the population and entity-culling settings are a legitimate lever, a slightly emptier ambient world can buy back headroom for scripts and player density where it matters. Tune these against measured tick time, not vibes, and change one value at a time so you can attribute the result.
Stream asset budgets
Streamed assets, custom vehicles, MLOs, clothing, and weapon models, are downloaded by every connecting client and held in memory. The two budgets to watch are the client download size (a multi-gigabyte initial download drives players away before they ever spawn) and in-game memory pressure from too many high-detail assets loaded at once, which shows up as texture loss, missing models, and client crashes rather than server lag. Audit your stream folders the same way you audit resources: remove add-ons nobody uses, prefer optimized models over the heaviest available, and treat every new vehicle pack as a cost, not a free feature. A lean, fast-loading server keeps more of the players who click connect.
Measure with resmon and txAdmin, not guesswork
Every change above should be verified, not assumed. Two tools cover almost all of it. resmon is the built-in resource monitor: connect to your server, press F8 to open the client console, and run resmon true (the server-side view is available to admins via resmon on the server console). It shows per-resource CPU time per tick, sort by it and the worst offenders are obvious. A resource averaging over 1 to 2 ms deserves a look; anything sustained over 5 ms is usually a real problem. txAdmin's dashboard shows the server thread's tick time and hitch graph over time, which is where you confirm that a config change actually moved the number. If resmon and txAdmin both look the same before and after an edit, the edit did nothing, regardless of how sensible it seemed.
For a full lag-diagnosis walkthrough using these tools, see how to fix FiveM server lag and high resmon usage, and for what the tick numbers mean, read FiveM server TPS explained.
Permissions, ACE rules, and admin groups
Copied-in ACE blocks from old templates often reference admin Steam identifiers or license strings that no longer belong to your staff. Stale identifiers grant server permissions to accounts you no longer control, which is a security issue. Audit every add_principaland add_ace line: remove identifiers for former staff, and ensure txAdmin is configured as the primary admin tool so permission management flows through a single interface. Never hard-code a Rockstar license as a superadmin if txAdmin already handles that role.
# Good: txAdmin manages admins, no hard-coded license superadmin
add_ace resource.monitor command allow
add_principal identifier.license:YOUR_LICENSE_HERE group.admin
# Bad: stale identifier from a former staff member still present
add_principal identifier.license:OLD_STAFF_LICENSE group.adminPerformance starts with knowing what is loading, why it loads, and whether it belongs in the launch build at all.