Why Internal Runbooks Are the Most Underrated Admin Tool on Any FiveM Server
Most FiveM servers run on institutional memory. One admin knows the restart command, another knows which script breaks when the database hiccups, and a third knows why half the jobs pay 12% less on weekdays. When any of those people disappear — real life, burnout, a fallout with the owner — that knowledge walks out with them. Server documentation turns three people's tribal knowledge into something the whole team can actually use.
What Belongs in a FiveM Server Runbook
A runbook is not a "rules for staff" document. It is the technical and operational reference that lets a new admin (or a returning one who hasn't touched the server in six months) walk in and handle situations without guessing. For a FiveM city it should cover at minimum:
- Restart procedure: the exact sequence to restart the server safely, which resources must come up in order, and what to check in console before opening the queue.
- Script dependency map: which resources require ox_lib, which share a database table with something else, and what breaks if any given resource fails to start.
- Config change log: every time a config.lua is edited, note what changed, why, and what the old value was. A simple text file or Notion page beats nothing.
- Economy parameters: current job pay rates, property prices, vehicle tier thresholds. Changes to these compound; tracking them lets you audit an economy that has drifted without knowing when it started.
- Incident post-mortems: a two-paragraph entry for each outage or exploit incident — what happened, what fixed it, what changed permanently.
Structuring Runbooks Your Team Will Actually Read
Documentation fails not because people don't want to write it but because what gets written is too long, too scattered, or too out of date to trust. Three format principles help FiveM servers specifically:
Short, Actionable Sections
Each runbook entry should start with a trigger ("When the economy database hits a locked table error") and end with a resolution ("Run X command, confirm in console, notify players via announce"). Paragraphs explaining context go below the procedure, not above it.
Version-Tagged Configs
Keep a /admin/configs/ folder in your private repo or server drive. When you change qb-banking/config.lua, drop a timestamped copy in that folder before and after. You will thank yourself when you need to roll back an economy change at 2 AM. Resources like those available through scripts-tebex.io often ship well-commented configs; use those comments as the starting point for your own inline documentation.
A Living Checklist for Onboarding Admins
New staff should complete a checklist: read the runbook, shadow two incidents, demonstrate the restart sequence, and know where economy parameters live. Skipping this is how you end up with admins who fix grief by spawning money instead of rolling back the affected player.
Job and Script Documentation
Every custom job on your server should have a one-page reference: what the job is, which scripts power it, what NPC or MLO it ties to, and what breaks if its core resource crashes. If you run a hospital script alongside EMS roleplay, note the resource name, the database tables it touches, and what admin commands exist to clear stuck states. Resources like hospital and EMS systems from store-tebex.io come with their own README files — pull those into your internal wiki rather than losing them in a Discord DM.
Security and Admin Access Documentation
Document every ace permission group that exists, who holds it, and what it allows. This sounds obvious but most servers accumulate ghost accounts and over-privileged roles over time. A quarterly audit against the runbook's access table reveals staff who left six months ago still holding superadmin. For a deeper look at structured permission hierarchies, the guides on febex.io cover ACE and txAdmin role design in detail.
Where to Keep Runbooks
A private Notion workspace, a GitHub repo with markdown files, or even a locked Discord channel with pinned pages — any of these beats nothing. The key property is that the whole admin team has access and knows where it is. Google Docs works for small teams; for anything over ten staff members, a proper wiki with search saves real time during incidents.
Making Documentation a Habit, Not a Sprint
The mistake is treating documentation as a project to complete. It's a reflex: any time a setting is changed, add a line. Any time an incident is resolved, write the post-mortem while it's fresh. Any time a new resource is installed, update the dependency map. Five minutes per event compounds into a server that survives staff turnover without skipping a beat.
Good internal documentation is also the foundation for scaling — when you're ready to push from 32 to 64 players, you need to know exactly what you're working with. The performance and infrastructure side of that expansion is covered on 0resmon-tebex.io, where script profiling and hardware guides help you identify the ceiling before you hit it.
A server with good runbooks runs like a real operation. A server without them runs on luck and whoever happened to be online when something broke.
