Debug a FiveM resource in three passes: configuration, code, then runtime

A resource can have valid Lua and still fail on a FiveM server. The server might not have discovered its folder, a dependency might be missing, or the code might expect a framework API your installation does not provide.

Treat these as separate checks. It makes the next change easier to choose and the result easier to explain.

Disclosure: this post is from RPScripts. The two browser tools linked below are ours and free to use. You can also follow the workflow manually.

Pass 1: Check what the server is being asked to start

Before editing code, write down the resource's exact folder name, required framework, dependencies and installation instructions. Compare that list with the resources actually installed on your test server.

Look for an accidental extra directory level after extracting a ZIP. The resource folder should contain its manifest; a download folder containing another folder containing the manifest deserves a closer look. Check path casing when moving files between Windows and Linux.

Read the active configuration, including any files it loads. Keep dependencies ahead of the resources that use them, according to the resource author's instructions. A line in server.cfg does not install a framework or create database tables.

The RPScripts server.cfg Builder & Checker can help review an existing configuration or create an annotated starter. It runs in the browser. A clean report cannot confirm that your resource files, database or license are correct; those still need a local check. Use placeholders when sharing configuration for support.

Pass 2: Inspect the resource before loading it into your server

Separate syntax problems from integration problems. A parser can identify malformed Lua, but it cannot establish that a database exists or that a particular vehicle appears correctly in the game.

For each resource, check:

• Does the manifest reference the scripts and UI files you actually shipped?
• Are client scripts and server scripts assigned to the intended side?
• Do required dependency names match the installed folders?
• Does an integration call an API supported by your installed framework version?
• Does server code validate permissions and derive important values itself, rather than trusting values supplied by a client?

The RPScripts FiveM Script Tester accepts a resource ZIP, a Lua file or pasted code. Its static checks and CfxLua sandbox run in the browser. The separate "Open in RPScripts AI" action sends files to your account, so distinguish that optional action from the local checks.

Read the scope of the result. Simulated frameworks and events help isolate some failures, but game-world natives, OneSync and real database behaviour still require a real server. A successful simulation is one piece of evidence, not a deployment certificate.

Pass 3: Run one controlled test on a staging server

Back up the resource and configuration first. Use a staging server with the dependencies and framework version you intend to deploy.

The official Cfx server-command reference distinguishes these operations:

• refresh rescans resource manifests so newly added resources can be discovered.
• start resource_name starts a stopped resource.
• ensure resource_name starts a stopped resource or restarts one that is already running.

That last distinction matters when other resources depend on state held by the resource you restart. Use a controlled maintenance or staging workflow instead of repeatedly issuing commands on a busy server.

Capture the first relevant server-console error and the corresponding client F8 output. Reproduce one action, change one cause, and repeat the same action. If it works, restart the staging server and test again: success after a manual start does not establish that a cold start has the right order.

Keep a short test record

Record the artifact version, framework and dependency versions, the action you tried, the result and the relevant log lines. Redact credentials before sharing anything.

Configuration checks answer whether the setup looks consistent. Resource checks answer what the code and simulation reveal. A staging test answers what happens in your actual environment. Keeping all three results makes support requests clearer and future updates easier to verify.