For the owner who runs it alone

What to check on your server every week

A FiveM server does not fail all at once. It drifts: a warning nobody read, a config a vendor update quietly reset, a pool that was fine before the last car pack, a player who crashes every night and stopped coming. This is the list a server is looked after by. About two hours a week done properly, less once it is habit.

After every restart · five minutes

Read the console, top to bottom, once. A clean boot banner is not proof. Look for a resource it could not find, two resources registering the same command, and anything that started with hundreds of warnings. Each is written up: ensured but not installed, same command twice, started with hundreds of warnings.
Confirm the change you made actually applied. Pool and gameconfig changes need a full restart, not a resource restart, and server.cfg values are read at boot only. Deployed but never applied is the most common "it did not work".
Join as a player, not as admin, for five minutes. Spawn, open the inventory, get in a car, use the phone. Admin accounts skip the paths players take.

Every week · about an hour

Check your paid scripts for releases. The framework watch on the front page shows ESX, QBCore, Qbox and ox releases as they land. For each vendor update, never copy the stock config over yours: compare the two configs and merge the new keys in. Why, and why being behind is not always a fault.
Pull a copy of every config you have tuned, and a database dump, off the server. "I can re-download it from the vendor" is not a backup of your settings. A backup you have never restored is a hope; restore one file from it once a month.
Run the health check. Paste your join code: artifact build against the current recommended one, OneSync, txAdmin, and the resource count. The recommended build moves; a server a year behind it is a server players cannot join after the next client update.
Look at your uptime for the week. Your uptime page shows every fifteen-minute check for seven days. A dip you did not notice is a restart you did not plan, and your players noticed it.
Look for the same player crashing twice. One crash is a client. The same crash twice, hours apart, is a file: usually a car. Paste the report into the crash checker, and read what the repeat tells you.
If you added cars or maps this week, recount the pools. Every texture dictionary and every distinct model counts against a pool, and the car named in the crash is the victim, not the cause. A game pool is full explains which one to raise.
After any ungraceful restart, check the garages. A restart that did not return vehicles leaves the database thinking every car is already out, and players open an empty garage. The flag to look at.

Every month · half an hour

Run your server.cfg through the checker. Paste the file: a resource started twice, a core started after what needs it, a stop after an ensure, a weak RCON password, settings that bite. It reads the file in your browser and sends nothing.
Audit who still has access. Every txAdmin admin, every FTP or SFTP user, every database user. Anyone whose job is finished should be gone. How access should have been given in the first place.
Check every paid script's licence is still active. A lapsed subscription on one resource can black-screen every player at join, with nothing in the console that says why. It looks like a crash and it is a billing date.
Stop what nothing uses. Resources ensured for a feature you removed months ago still load, still take memory, still print warnings. Read the ensure list once and ask what each line is for.
Anything new going on the server gets scanned first. Drop the zip in the pre-scan before it is uploaded. A pack sold as a carry script turned out to be a Discord token stealer; the scan is how that was caught.