Why FiveM servers slow down the longer they run
A FiveM server does not stay at peak performance forever. The FXServer process, the resources you run, and the database connections behind them all hold on to memory and state while the server is live. The longer uptime stretches, the more small inefficiencies stack up. This is the core reason scheduled restarts exist, and it is why even well tuned servers benefit from a clean restart on a fixed cycle.
The usual symptoms are familiar to any server owner. Server frame time creeps upward, the OneSync tick gets heavier, players report rubber banding and delayed interactions, and resources that were snappy at hour one feel sluggish at hour fifteen. None of this means a resource is broken. It often just means the process has been running long enough to collect garbage it never fully releases.
Memory creep over uptime
Memory creep is the slow growth of memory use that you cannot fully explain by player count. A Lua resource that creates tables in a loop, a script that registers event handlers without cleaning them up, or a third party resource with a small leak will each add a little to the heap every hour. Individually these are tiny. Across a full day of uptime on a busy server they add up to noticeable slowdown and, in the worst case, a crash when the host runs out of headroom.
The FiveM artifacts and the Lua and JavaScript runtimes do garbage collect, but garbage collection reclaims unreachable memory, not memory that a script is still technically holding a reference to. A restart is the only thing guaranteed to return the process to a known clean baseline. That is the mechanism behind the common advice that restarts help performance: they reset the slate rather than patch the leak.
How txAdmin scheduled restarts work
txAdmin is the official web based management panel that ships with the FiveM server artifacts. It runs as a wrapper around FXServer, which means it can stop and start the server process on a schedule without you touching the machine. This is the recommended way to automate restarts because txAdmin also handles the warnings and the graceful shutdown for you.
To set it up, open the txAdmin panel in your browser, go to Settings, then the Restarter section. There you define scheduled restart times as a list of clock times in twenty four hour format, for example 06:00, 12:00, 18:00, and 00:00 for a six hour cycle. txAdmin reads these as times of day in the server timezone, so the schedule repeats every day at those exact moments.
Restart warning resources and messages
When a scheduled restart approaches, txAdmin broadcasts warnings to connected players automatically. By default it announces the upcoming restart at several intervals before it happens, counting down so nobody is caught mid action. These warnings are sent through txAdmin's own announcement system and appear in chat and as on screen text.
You can shape how those warnings look and feel. txAdmin exposes the schedule and restart events to your resources, so you can listen for them and trigger custom behaviour. A common pattern is a resource that listens for the txAdmin restart announcement and shows a styled on screen banner, plays a sound, or freezes new transactions in an economy script so no money is lost in the final seconds. The mechanism is event driven: txAdmin emits the warning, your resource reacts.
Graceful player warnings
Graceful means players get enough notice to reach a safe state. On a roleplay server a sudden restart can interrupt a scene, drop a player mid heist, or cut off a sale. A good warning ladder gives a fifteen minute heads up, then five, then one minute, then a final ten second countdown. txAdmin's defaults already approximate this, and you can tune the exact intervals to match your community's pace.
The goal is predictability. If players know restarts happen at the same four times every day and they always get a clear countdown, they plan around it. The restart stops being a disruption and becomes a routine part of the server rhythm, like a shift change.
Why 6 to 12 hour cycles are the sweet spot
The right cadence balances two costs. Restart too often and you annoy players with constant interruptions and brief downtime. Restart too rarely and you let memory creep and frame time degradation pile up until the experience suffers or the server crashes on its own schedule rather than yours.
For a busy roleplay or racing server with a heavy resource list and high concurrent player counts, six hours is the common standard. It keeps frame time tight and clears memory before creep becomes visible. Many of the largest communities run four restarts a day at 06:00, 12:00, 18:00, and 00:00 for exactly this reason.
Lighter servers, smaller communities, or stripped down builds can comfortably stretch to twelve or even twenty four hours. If your frame time stays flat and memory use is stable across a full day, you do not need to restart more often just because someone said so. Watch your own metrics and let them set the cadence.
Example: tuning a real schedule
Say you run a medium QBCore server with around eighty concurrent players. You start on a twelve hour cycle, restarting at 06:00 and 18:00. After a week you check txAdmin's performance charts and notice frame time climbing past the ten hour mark each cycle, with the worst lag complaints arriving just before the 18:00 restart. The fix is straightforward: move to a six hour cycle, adding 12:00 and 00:00. The added midday and midnight restarts cut the worst of the creep, and the complaints stop. This is the concept, mechanism, and example loop in practice: you observe degradation over uptime, you understand it as creep, and you shorten the cycle to match.
Persistence considerations
A restart wipes the server's runtime state, which is exactly the point. The danger is when something important lives only in that runtime state and never reaches the database. Anything a player did since the last save must be persisted before the process stops, or it is gone.
Most frameworks like QBCore and ESX save player data on disconnect and on a periodic timer. The risk window is the gap between the last save and the restart. If your framework saves every five minutes and the restart fires between saves, players can lose the last few minutes of inventory changes, cash, or position. The fix is to make sure a final save runs as part of the shutdown. txAdmin gives the server a brief graceful window to stop resources cleanly, so a well written framework will flush data during that window. Confirm your framework does this, and if you run custom economy or inventory resources, make sure they hook the player dropped and resource stop events to save on shutdown.
The practical rule is simple. Test a restart on a quiet server, make a tracked change just before it fires, and confirm the change survived. If it did not, your persistence has a gap that the restart schedule will expose every single day.