Memory leaks are a fact of life on FiveM. Even a tight resource stack accumulates orphaned state bags, uncollected Lua tables, and dead threads over 6–12 hours. Automated restarts are how you drain that before players notice. The question isn't whether to automate them — it's how to build the schedule so restarts happen cleanly, crash recovery kicks in instantly, and players get enough warning to wrap up their scene instead of rage-quitting.
txAdmin Scheduled Restarts: The Baseline
txAdmin ships a scheduler under Settings → Schedule. You pick times in UTC, enable announcements, and FXServer handles the rest. The default announcement fires at 15 minutes, 10 minutes, 5 minutes and 1 minute before shutdown, broadcasting through txAdmin's built-in announcement system which hooks into both in-game chat and your configured Discord webhook.
A typical 24-hour schedule for a medium-population server: 06:00 UTC (night restart — lowest population, no warning needed), 14:00 UTC (afternoon restart with full warning chain), 22:00 UTC (peak-adjacent restart, maximum warning lead time). Three restarts per day is enough for most stacks. Going tighter than every 4 hours creates churn without proportional gain unless your server has a specific known leak.
The Announcement Hook
txAdmin fires the txAdmin:events:scheduledRestart event at each warning milestone. Listening to this in a server-side resource lets you do things the built-in announcer can't — pause job progress, save player metadata to the database before shutdown, trigger a blip countdown on the minimap, or broadcast a custom NUI overlay. The payload includes secondsUntilRestart, which you can use to branch logic: at 300 seconds, freeze new criminal actions; at 60 seconds, auto-save and display a full-screen count.
AddEventHandler('txAdmin:events:scheduledRestart', function(data) local secs = data.secondsUntilRestart if secs == 300 then -- trigger autosave for all players elseif secs == 60 then TriggerClientEvent('yourresource:client:showCountdown', -1, secs) end end)
Crash Recovery: Watchdog and Heartbeat
Scheduled restarts handle planned downtime. Crash recovery handles the unplanned kind. txAdmin's watchdog monitors the FXServer process and the game's heartbeat signal. If the heartbeat stops arriving — whether from a script deadlock, an OOM kill, or a native crash — txAdmin detects the absence within its configured timeout and relaunches the server automatically.
The critical setting here is Server Boot Timeout in txAdmin's diagnostics config. Set it too short and a slow database connection at boot triggers a false positive restart loop. Set it too long and a genuinely hung server sits dead for minutes. 120 seconds at boot, 60 seconds for the live heartbeat check, is a reasonable starting point for most VPS-hosted servers.
What Crash Recovery Can't Fix
Watchdog restarts the process — it doesn't fix whatever caused the crash. If a script enters an infinite loop in a CreateThread with no Wait() call, the server will recover, then crash again on the same resource. Always pair crash recovery with server-side logging. A Discord webhook on the txAdmin:events:serverShutdown event gives you a timestamp trail. Three crashes within an hour almost always point to one resource; resmon output captured before the crash narrows it to a specific script.
Graceful Shutdown: Saving Player State Before the Restart
The worst outcome from a restart isn't downtime — it's rollback. A player who spent 20 minutes robbing a store loses progress because their inventory write hadn't flushed to the database yet. The fix is explicit pre-shutdown saves triggered by the warning events, not passive write-through that happens to run before the kill.
In QBCore, QBCore.Functions.GetPlayers() returns all connected source IDs. Iterate them at the 60-second warning, call exports['qb-core']:GetPlayer(src).Functions.Save() on each, and confirm the save with a server print. ESX equivalent is ESX.GetPlayers() with xPlayer.save(). This adds 3–5 seconds of database writes but removes rollback risk entirely. For ox_inventory, call exports.ox_inventory:saveInventory() explicitly — it does not save on event-triggered shutdown by default in all versions.
Custom Restart Scripts vs txAdmin's Scheduler
Community restart resources like esx_restarter or standalone scheduler scripts predate txAdmin's built-in scheduler and predate OneSync. Most of them fire TriggerClientEvent to all players, which under OneSync Infinity can miss players outside the server's entity bubble if the resource has a badly scoped net event. txAdmin's event system routes through the server process itself and doesn't have this scope problem. Unless you need something the built-in scheduler genuinely can't do — per-event restart suppression, dynamic schedule reloading from a config file — stick with the txAdmin scheduler and extend it through the event hooks rather than replacing it.
Restart Windows and Player Communication
Timing matters as much as mechanism. Restart windows should align with population dips: check your txAdmin player graph over two weeks and pick the 15-minute valleys. Announce scheduled times publicly on Discord and in-game so players internalize the rhythm. Servers that restart predictably at the same times daily see less frustration than servers that restart randomly at the same total frequency — players plan around known downtime, they can't plan around surprise shutdowns.
For the in-game experience, a blip on the map or a persistent chat message starting at 10 minutes outperforms a single announcement at 5. Players in the middle of a job miss single-shot messages. Repeated or persistent notices — using exports['chat']:addMessage on an interval — reach more of the population before the cut. Pair that with a server-side countdown resource that tracks the next scheduled restart and exposes it via exports so any resource can query time-to-restart without duplicating the schedule logic. For curated restart-compatible scripts that handle pre-shutdown saves cleanly, scripts-tebex.io and store-tebex.io are worth checking — the better resources document their shutdown behavior explicitly. If you need a full managed stack where restarts are already tuned into the framework, qb-tebex.io shows how QBCore-oriented builds handle graceful shutdown at the framework level.
