txAdmin scheduled restarts: set a daily restart with warnings

A FiveM server that runs for days slowly gets worse: memory grows, scripts leave entities behind, and hitches become more common. A scheduled restart at a fixed hour is the cheapest fix. txAdmin has it built in, with warnings to the players so nobody is surprised.

#Why daily restarts help

• Memory. Some resources keep adding to tables or entities they never clean up. A restart returns the server to a fresh state.
• Stuck state. Leftover entities, broken sessions and scripts in a bad state disappear.
• Predictability. Players learn that the server goes down at, say, 05:00 and plan for it.
• Updates. You have a regular point to apply script updates and new artifacts. See updating server artifacts.

A restart hides a leak, it does not fix it. If the server is clearly slower after a few hours, find the cause with resmon.

#Set the schedule in txAdmin

1. Open the txAdmin web panel and go to Settings.
2. Find the Restarter (scheduled restarts) section.
3. Add the times of day when you want a restart, in the format shown, for example 05:00. You can add more than one.
4. Save.

The exact layout varies by version, so look for the restart schedule section. Times follow the clock of the machine that runs txAdmin, so check its timezone if the restart happens at the wrong hour.

Pick the quietest hour of your server. Check your player graph before choosing.

#Warnings before the restart

txAdmin announces upcoming restarts to the players in game, with a countdown. You do not have to write a script for this. When a restart is scheduled, players get messages in the minutes before, and the final message when it begins.

You can also restart by hand from the panel at any time and give a reason. The message is shown to the players first.

Tip: tell your players the restart hours in your Discord and on your loading screen. Few people will mind a restart they were told about.

#Save player data on shutdown

The risk of a restart is lost progress. Think of it as three layers:

1. The framework saves characters periodically and when a player disconnects (playerDropped). ESX, QBCore and QBox all do this. When txAdmin stops the server, players are disconnected, which triggers those saves in normal conditions.
2. Your scripts should keep their own data in the database as it changes, or on a timer. Do not hold progress only in a Lua table and write it at shutdown.
3. Shutdown hooks are a last chance, not a plan. A server that is killed or crashes never runs them.

txAdmin sends events to your resources that you can use, for example when a scheduled restart is coming and when the server is shutting down. Two of them are txAdmin:events:scheduledRestart and txAdmin:events:serverShuttingDown. Both are server-side events.

AddEventHandler('txAdmin:events:scheduledRestart', function(eventData)
    if GetInvokingResource() ~= 'monitor' then return end
    -- eventData holds the time left and the announcement text
    print('A restart is scheduled soon')
end)

AddEventHandler('txAdmin:events:serverShuttingDown', function(eventData)
    if GetInvokingResource() ~= 'monitor' then return end
    -- save anything your script still holds in memory
    SaveAllMyData()
end)

The GetInvokingResource() check makes sure the event comes from txAdmin (its resource is called monitor) and not from a player or another script. Check the txAdmin documentation for the full list of event data fields in your version.

SaveAllMyData stands for your own function that writes your script's state to the database. Keep it fast: the server does not wait forever.

#Practical tips

• Restart less often than you think you need, but not never. Once a day works for most servers. Heavy servers do twice.
• Back up before the restart. A database dump scheduled a few minutes earlier means you can always go back. See backing up your server.
• Watch the first start after a restart. If a script fails to start, you want to know before players join. Check the txAdmin console.
• Use resource order. Scripts that need a database or core must start after them. See server.cfg resource order.
• Do not restart during events. If you run a scheduled event, move the restart or do it by hand afterwards.

#What a restart does not fix

If the server hitches or lags from the moment it starts, the problem is a script, not uptime. Check server thread hitch warnings and resmon. A schedule only treats the slow build-up.

#Checklist