FiveM

FXServer crash loop (server keeps restarting)

An FXServer crash loop is when the server process starts, runs for a few seconds or minutes, crashes or gets killed, and then the process manager (txAdmin, systemd, screen) restarts it immediately — causing the cycle to repeat. Players can't stay connected, and if the crash happens early in startup, they can't connect at all. The key is finding the crash cause in the last log before chasing the loop.

Fastest path: paste your crash report into the Crash Doctor — it identifies this pattern and 40+ others automatically. No signup.

How to fix it

  1. 1

    Stop the crash loop first

    Use txAdmin's stop button, 'systemctl stop fivem', or kill the FXServer process. The loop must stop so you can read a stable log. Running txAdmin's 'restart' while in a loop just creates more log noise.

  2. 2

    Read the last crash log

    FXServer writes logs to FXServer/server-data/logs/ (txAdmin) or the directory you specified. Open the most recent .log file and scroll to the very end — the last lines before shutdown name the crash cause. Look for 'Error' or 'FATAL' or a Lua script error with a resource name in brackets.

  3. 3

    Disable or remove the crashing resource

    Comment out the 'ensure [resource]' line in server.cfg for the resource named in the error. Restart once to confirm the crash loop stops. Once stable, investigate what's wrong with that resource (missing dependency, config error, Lua syntax error) before re-enabling it.

  4. 4

    Check for global Lua errors that affect all resources

    If the log shows a Lua error in a framework file (esx_core, qb-core, ox_lib) rather than a specific script, the framework itself has a problem. Common causes: MySQL not connected (oxmysql dependency not started), a framework config file with a syntax error, or a framework version mismatch with a core resource.

Alternative causes

These can produce the same error message — worth ruling out if the steps above don't resolve it.

FXServer binary crashing (native crash, not a Lua error)

If the server dies instantly with no Lua errors in the log, FXServer itself crashed natively. Check system RAM (free -h), disk space (df -h), and kernel OOM messages (dmesg | grep -i kill). Native crashes often mean the host ran out of memory mid-startup.

txAdmin watchdog triggering on a false positive

txAdmin has a server health check that restarts FXServer if it stops responding. If FXServer is loading a heavy resource slowly, txAdmin may mistake it for a crash and restart it. In txAdmin settings, increase the 'Server Restart Threshold' to give the server more time to load.

Frequently asked

How do I find which resource is crashing if the log isn't clear?

Binary search: comment out half the ensure lines in server.cfg and restart. If stable, the crashing resource is in the disabled half. Re-enable half of those, repeat. Usually takes 3-4 iterations to isolate the culprit.

Can a resource cause a crash loop if it wasn't there before?

Yes — updating a resource or its dependencies can introduce a crash. If the loop started after you added or updated something, that's your first suspect. Roll back that change.

Does txAdmin prevent crash loops?

txAdmin restarts the server after crashes (which is good) and has a 'max restarts' safeguard to stop infinite loops (configurable). If you see txAdmin's 'maximum restarts reached' message, it intentionally stopped restarting — check the log for root cause.

Want this auto-fixed on your server?

CoalHosting's Minecraft hosting runs the same pattern database against every crash and applies the known fix before your players notice. Free crash diagnosis works on any server, hosted or not.

Related crashes

Last reviewed 2026-06-15. If a step is wrong or out of date, tell us — we'll fix the article and the auto-pattern at the same time.