When FiveM remains on a loading screen, first determine whether the failure affects one client, one server or every player after a resource change. Preserve the exact screen text and console error, test one known-working server, and change one reversible cause at a time. Do not begin with undocumented security convars or a blanket deletion of application and server data.
Classify the failure before changing files
| Observed scope | Start here |
|---|---|
| One player, multiple servers | Client process, official client issue, GTA/FiveM installation and local cache diagnosis. |
| One player, one server | F8 error, connection path and the first resource or download that fails for that client. |
| Every player on one server | FXServer/txAdmin console, recent deployment, resource startup and database/dependency health. |
| Only after a custom loading screen change | Loading-screen manifest, browser console and manual-shutdown lifecycle. |
Player-side checks
- Record the exact server, time, loading text and any visible error.
- Press F8 and capture the first relevant error rather than the repeated lines that follow it. Cfx.re documents F8 in its client console reference.
- Try another known-working server. If that also fails, follow the exact current Cfx.re client-issues guidance.
- Restart FiveM and Windows once to release locked processes.
- If evidence points to cached server assets, use the reversible procedure in the FiveM cache guide. Do not delete the whole application-data directory.
Server-owner checks
- Freeze deployments and export the relevant FXServer/txAdmin log around one failed connection.
- Check whether the problem started immediately after a resource, artifact, configuration or database change.
- Use txAdmin’s Live Console and resource controls to identify the first failed dependency. txAdmin is bundled with FXServer and its current monitoring features are documented in the official txAdmin guide.
- Verify required services and database access without printing credentials.
- Roll back the last owned change or disable only the isolated resource on a development instance.
Check resource startup and dependencies
A resource can stall onboarding when it waits forever for an export, database result, framework object or client event. Review the server log for “could not find dependency”, parse errors and timeouts. Make startup order explicit with dependency In fxmanifest.lua or a correct ensure sequence; do not hide the failure with arbitrary sleeps.
On a development server, refresh rescans manifests and ensure resource-name starts or restarts one resource. These commands are defined in the official server-command reference. Avoid restarting a production dependency without understanding which active sessions use it.
Custom loading-screen failures
If the game is ready but a custom screen never closes, inspect whether the resource uses loadscreen_manual_shutdown 'yes'. That mode requires a client script to call ShutdownLoadingScreenNui() after a real ready condition. Remove the manual-shutdown directive to return to automatic behaviour while debugging. The supported lifecycle and progress events are documented in the Cfx.re loading-screen guide.
Avoid unsafe generic fixes
- Do not copy undocumented
sv_*security values from an unrelated error guide. - Do not disable antivirus or firewall protection permanently.
- Do not delete a live database, txAdmin data directory or complete FiveM installation before preserving a backup.
- Do not add repeated client retries that grant items, money or permissions more than once.
- Do not call a longer loading timeout a fix when the underlying resource still fails.
Verify the repair
Repeat the same connection on the affected client, a clean second client and after a full server restart. Confirm that the first console error is gone, the player reaches a usable state, required resources started once and no duplicate entitlement or inventory action occurred. Keep the rollback until the result survives the restart.