Fixing "Couldn't start resource" in a FiveM roleplay server

"Couldn't start resource <name>" is the message FiveM prints when it refused to load one of your scripts at boot. It is different from a runtime SCRIPT ERROR: the resource never even reached the running state. Almost always the reason is printed in the lines directly above the message, so the fix starts with reading the console, not restarting blindly.

The three real causes are a broken manifest, a missing dependency, and wrong load order. This guide shows you how to tell them apart from the console output and fix each one, plus a fast recovery process for when the cause is not obvious.

Read the lines above the message first

FiveM tells you why it gave up, but the reason is on the line before "Couldn't start resource", not on that line. Scroll up in your txAdmin live console or server terminal and look for the matching resource name in brackets, like [c-scripting-core] or [my_resource].

You will usually find one of three explanations: a manifest parse error (the fxmanifest.lua has a syntax mistake), a failed dependency (a resource it needs is not running), or a missing file (the manifest references a file that is not there). Each has a distinct fix, so identify which one you have before touching anything.

• Search the console for the resource name in square brackets
• Look for keywords: "Failed to load", "could not parse", "no such file", "dependency"
• Read the last 50 lines around the error; the cause is rarely the literal last line

Cause 1: a broken or missing fxmanifest.lua

Every resource needs a valid fxmanifest.lua (or the older __resource.lua). If it is missing, malformed, or missing the mandatory fx_version and game lines, FiveM cannot start the resource. A trailing comma, an unclosed brace, or a smart-quote pasted from a website will all break the parse.

Open the manifest and confirm the basics are present: fx_version 'cerulean', game 'gta5', and your client_scripts / server_scripts / shared_scripts blocks. Make sure every string uses straight quotes and every list of files is wrapped correctly. If the console says "could not parse" or points at a line in fxmanifest.lua, the syntax is your problem.

A subtle version of this is referencing a file that does not exist. If your manifest lists client_scripts { 'client/main.lua' } but the file is actually client/client.lua, FiveM fails to start the resource because it cannot find the declared file. File names are case-sensitive on Linux servers, so Client.lua and client.lua are not the same.

Cause 2: a missing or unstarted dependency

Many resources declare a dependency in their manifest, like dependency 'ox_lib' or dependencies { 'oxmysql', 'es_extended' }. FiveM treats this as a hard requirement: if any listed dependency is not already running, it refuses to start the resource as a safety check, and you see "Couldn't start resource".

Open the failing resource's fxmanifest.lua and read the dependency / dependencies field. Then confirm every name there is installed and ensured earlier in your server.cfg. The dependency must appear before the resource that needs it, because FiveM starts resources top to bottom in the order they are ensured.

If the dependency exists but is also failing to start, fix that one first. Dependencies cascade: if oxmysql fails, everything that depends on it fails too. Resolve the root resource and the rest often start cleanly.

Cause 3: wrong load order in server.cfg

FiveM starts resources in the exact order they appear in server.cfg. If script A uses an export from script B, but A is ensured before B, then A starts before B exists and either crashes or fails to start. The fix is to order the foundation first.

A safe baseline order for a roleplay server is: oxmysql, then ox_lib, then your framework (es_extended or qb-core), then shared libraries like ox_target and ox_inventory, then all your custom scripts last. Put your gameplay scripts at the bottom so everything they rely on is already running.

Note that ensure inside a folder (using a category in your cfg) does not guarantee order between folders. When in doubt, ensure critical dependencies explicitly and individually near the top rather than relying on a bulk start.

A clean recovery process

When one resource refuses to start and the cause is not obvious, narrow it down fast. Comment out half your custom resources in server.cfg, restart, and see if the problem disappears. Keep halving until you isolate the offending resource. This binary search beats removing them one at a time when you run dozens of scripts.

Once isolated, re-read that resource's manifest and console output with fresh eyes. Building scripts with an AI workflow like PlayDeck's helps here because the AI can read the manifest and the error together and point at the exact mismatch, while you decide on the fix and keep ownership of your code. Want to learn this hands-on? Join the PlayDeck waitlist.