Reliable network event overflow in FiveM: find the script and fix it

A player is thrown out of the server, or the whole server starts timing out, with a message like this:

Reliable network event overflow

FiveM keeps a limited queue of reliable network events for each connection. When a script fills it faster than the connection can send, the player is dropped. The cause is almost always one resource. Here is how to find it and fix it.

#What happens

Every TriggerClientEvent and TriggerServerEvent is a reliable message: it must arrive, in order. If you send many of them, or very large ones, the queue for that player grows. When it overflows, the connection is cut.

The usual patterns:

• A large table sent in one event: a full list of vehicles, items, players, or a whole config.
• A loop that triggers an event on every tick or every few milliseconds.
• An event sent to everyone (-1) many times per second.
• A script that sends the same data again and again, when it did not change.

-- bad: sends everything, to everyone, every 100 ms
CreateThread(function()
    while true do
        Wait(100)
        TriggerClientEvent('myscript:update', -1, GetAllData())
    end
end)

#Find the resource

The error message does not name the script, so you have to measure.

1. Look at the server console around the time of the kicks. Many identical event names, or a resource that started just before the problems, is a hint.
2. Use the profiler. The built-in profiler records a short session and lets you open it in a viewer. In the server console:

profiler record 500
profiler view

Check the exact commands for your server build, since they can change between versions. The recording shows which resources and events take time, and helps you spot the heavy one.

3. Stop resources one at a time on a test server. If the kicks stop after you stop a resource, you found it.
4. Search the code for TriggerClientEvent and TriggerServerEvent inside loops, and for events sent with -1.

Tip: the problem often starts after you add a new script, or after a script update. Check what changed first.

#Fix 1: send smaller payloads

Send only what changed, not the whole data set.

-- bad: the whole table
TriggerClientEvent('shop:sync', src, allShops)

-- better: only the changed entry
TriggerClientEvent('shop:updateOne', src, shopId, shops[shopId])

Strip fields the client does not need, send ids instead of whole objects, and let the client request details when it needs them.

#Fix 2: send less often

Trigger events when something happens, not on a timer. If you need a timer, make it slower and skip it when nothing changed.

local last = nil

CreateThread(function()
    while true do
        Wait(2000)
        local data = GetData()
        if data ~= last then
            last = data
            TriggerClientEvent('myscript:update', -1, data)
        end
    end
end)

Send to the players that need it, not to -1, when only some players care.

#Fix 3: latent events for big data

When you really must send a lot of data, such as a large config or an image, use a latent event. It sends the data in the background at a speed you set, in bytes per second, instead of filling the normal queue.

-- server -> client, 50 KB/s
TriggerLatentClientEvent('myscript:bigData', src, 50000, bigTable)

-- client -> server
TriggerLatentServerEvent('myscript:bigData', 50000, bigTable)

The event arrives later, so use it only for data that is not time critical. Choose a speed that does not saturate the player's connection.

#Fix 4: state bags for shared state

If the data is state of an entity or a player (a flag, a value, a status), a state bag is often better than events. FiveM replicates changes for you, and only sends what changed.

-- server
Player(src).state:set('isCuffed', true, true)

-- client, anywhere
local cuffed = LocalPlayer.state.isCuffed

State bags are for small values, not for large tables. Read FiveM state bags explained for how they work, and Client and server events in FiveM for the basics of events.

#If you cannot edit the script

If the script is a paid or protected resource, you cannot change its code. Report the problem to the author with the profiler result and the time of the kicks. They will know which event is too big. Until then, stopping the resource or lowering its refresh rate in its config, if it has one, is the only workaround.

#Checklist