At 2:14am your server drops. txAdmin tries a restart, the database sits there refusing to answer, and by 2:20 your Discord has sixty messages in general chat, eleven of which are just the word "down?" and one of which is someone confidently explaining that Rockstar is patching. Your staff say nothing, because nobody wants to be the admin who promised twenty minutes and delivered five hours. At 3:40 you finally post something. A good chunk of your regulars are already on another server where the queue was moving. The fivem server downtime ran two and a half hours. The first eighty six minutes of it were silence, and that silence is the part that cost you players.
Players forgive a dead server. Most of them have run one, and they know machines quit at inconvenient hours out of pure spite. Being left in the dark while somebody who clearly knows what's happening decides whether to mention it is the thing that makes them go looking elsewhere.
So this is a communications guide rather than a recovery guide: maintenance windows that match your players instead of your sleep schedule, how much warning to give and where to put it, what a status update says when you don't yet know what broke, the post-incident note, rollbacks that eat somebody's evening, compensation that backfires, and how to stop five admins publishing five different ETAs.
Planned and unplanned fivem server downtime are two different jobs
Planned maintenance is the easy one, and people still fumble it, usually by deciding it's too small to announce. A "quick ten minute update" pushed at peak is ten minutes of your time and about forty five minutes of theirs, because players who get dropped mid-scene don't stand around refreshing. They go to bed, or they go somewhere else. You chose the hour, so pre-write every message, schedule it, and be thoroughly boring about it. Boring is the win condition here.
Unplanned downtime is the one that tests you. No ETA, no cause, sometimes no console access, and a Discord filling up faster than you can read it. The only thing you actually control in the first ten minutes is whether you said anything. Post inside five minutes even when the post contains no information: "we know, we're looking, next update at 02:35" outperforms a beautifully detailed explanation ninety minutes later.
That first post also settles who does what. Whoever is elbow deep in the console working through why the server won't boot should not also be the person typing in Discord. Splitting those two roles is the cheapest improvement most servers can make to how an outage feels from outside.
How to pick a maintenance window your players are actually asleep for
Most owners pick a window based on their own night, which works right up until you notice that a third of your city is in Brazil and your tidy 4am slot is their prime street racing hour.
Your database already knows the answer. Pull session start times from your player or connection log for the last fourteen days, bucket them by hour in UTC, and take the median concurrency per hour rather than the peak. The trough is your window. Do it twice, once for weekdays and once for weekends, because they're rarely the same shape: a Europe heavy server often bottoms out around 05:00 to 07:00 UTC, while a US heavy one won't hit its floor until closer to 10:00. Whatever the numbers say, do not touch Friday or Saturday evening in your largest timezone bucket.
Then double whatever duration you estimated. If you think thirty minutes, announce ninety. Finishing early is a free gift, and overrunning your own announced window burns the credibility you'll need next time. The window also isn't over the moment the server accepts connections. Resources are still starting, the database pool is still waking up, and the first players back in are your unpaid test suite. Call it done when it's stable.
How much notice to give, and the three places players will actually see it
The ladder that works: 48 hours out, 24 hours out, one hour out, and at the door. Attach your role ping to the 24 hour post only. Ping four times and people mute the channel, and a muted announcements channel is exactly where your next emergency notice goes to die.
Post it in three places, because each one catches a different person.
In-game, while they're playing. Chat scrolls away in about nine seconds during a busy night, so use a persistent on-screen notification or let txAdmin's scheduler fire the warnings for you at the 60, 30, 10 and 1 minute marks. The player mid-heist deserves to know before the screen goes black.
Discord, in an announcements channel where only staff can post. Add a Discord scheduled event too, so the window shows up in the server sidebar and people can actually see it coming rather than scrolling for it.
The connect screen, which is the one everybody forgets and the only one that reaches the player who isn't in your Discord at all. Put the window in sv_projectName or sv_projectDesc so it shows in the server browser, and drop a line on your loading screen. Somebody who hits a connection error and finds no explanation anywhere assumes you died, and servers do die, which is why they go looking for a replacement.
What to put in a status update when you don't know the cause yet
A status update during an active incident contains four things and nothing else:
- What's broken, in player language. "Nobody can connect" beats "the MySQL connection pool is exhausted", even if the second one is what you're staring at.
- What you're doing right now. One sentence. This is not the moment for a technical flex.
- When you'll post next. A clock time, not an interval, because "in a bit" restarts the whole problem.
- Nothing else.
That fourth item does the heavy lifting. No guessing at causes you'll have to retract, no naming your host in a temper, no "should be quick", and absolutely no promising compensation while the building is still on fire.
A pinned template means the person typing at 3am isn't also designing a format:
[03:40 UTC] Server is offline. Players cannot connect.
What we know: the database is not accepting connections.
What we're doing: restoring the database service, no data loss expected.
Next update: 04:10 UTC, whether or not it's fixed.Then hold the cadence: every twenty to thirty minutes for the first couple of hours, hourly after that if you've settled into a long repair. "No change, still working, next update 04:40" is a complete and valid update. People measure the gaps between your posts far more than the content of them, and a missed self imposed deadline reads as abandonment even when you were making progress.
If the failure is upstream at Cfx.re rather than yours, say so plainly and point people at status.cfx.re. "This one isn't ours, here's the page, we'll be up the moment they are" is an honest and complete answer, and it takes ten seconds.
Why "soon" is the worst word in your announcements channel
Soon. Shortly. ASAP. Momentarily. Every player who reads one of those converts it into a private number, and no two of those numbers match. One person hears fifteen minutes, another hears an hour, and at the sixteen minute mark you have broken a promise you never actually made.
My dad has been saying the shed will be finished "soon" since 2017. There is still no shed. There is, however, a very confident pile of wood.
Give a floor, never a ceiling. "At least two hours, possibly longer" beats "about an hour" even when the truth turns out to be ninety minutes, because coming back early is a present and coming back late is a lie you told in advance. And if you honestly cannot estimate, say that: "we don't have an ETA yet, next update at 04:10" is a full answer. It releases people to go and do something else with their evening.
Writing the post-incident note without handing an attacker a map
Publish within twenty four hours, while people still care. Two hundred words, one screen, no PDF. It needs a timeline in real clock times, a description of what broke at the layer players actually experienced, and what you changed so it doesn't happen again. Add one line admitting what you got wrong in the response itself. "We should have posted at 02:20 and we posted at 03:40" buys more goodwill than any amount of technical detail.
Leave out the version numbers, the specific resource with the hole in it, the exact query, your provider, your ports, and above all your thresholds. If the cause was an attack, "we absorbed a volumetric attack and moved traffic behind filtering" is the entire public story. How you actually handle attack traffic at the edge stays in your own notes, because publishing your mitigation numbers is publishing the score somebody has to beat.
Telling players a rollback ate their evening, and paying for it properly
Say the restore point as a wall clock time, and say it first. "We restored to 21:40. Anything after 21:40 is gone: money earned, items bought, vehicles purchased, character edits." Vague phrasing like "some progress may be lost" makes every player assume the worst about their own stuff and come argue it individually, one ticket at a time.
Post it before they find out on their own. A player discovering their new car is missing three days later concludes you hid it, and that conclusion is very hard to reverse.
Write your restore policy before you need it: restore what the logs prove, nothing from memory, same rule for your staff and your biggest donor as for the person who joined last Tuesday. Skip this and "whoever complains loudest" becomes your policy, and you'll be honouring it forever. If your ticket flow is already routed through proper player feedback and reporting systems, this gets a lot less painful, because you're reading structured reports instead of scraping symptoms out of four hundred panicked chat messages.
Compensation helps when players lost something real that you genuinely cannot give back, and it works best flat and universal: same thing for everyone affected, no draw, no tiers, no winners. It stops helping the moment it becomes routine. Compensate a twenty five minute restart and within two months somebody will be asking when the next outage is because they're saving for a car. That's your own training programme coming back to bite you.
Where you can, pay in time rather than currency. A double payout weekend, one bonus paycheck cycle, a week of priority queue. They pull people back into the city to claim them, and they don't dump a pile of cash into an economy you spent months balancing.
One voice, one channel, one person allowed to give a time
Nominate an incident lead at the start of every outage, and route everything through them, including you when you're in the console. Staff speculation lives in a staff channel. The rule that prevents the most damage is short enough to pin: nobody except the lead posts a time. Everyone else says "we're aware, updates are going in #status" and then stops typing.
The infrastructure behind this takes about ten minutes to set up, once. A #status channel where only staff can post and nobody can chat, so that six months later the timeline is readable at a glance. A #server-chat next door where the meltdown is allowed to happen. A pinned template. And a decision, made in advance, about who's authorised to post if you're asleep, because an outage that waits for the owner to wake up isn't a two hour outage any more.
The trust maths
Two servers take the same three hour hit on the same Tuesday. One posts at 2:19, updates every half hour, and publishes two hundred words the next morning admitting it should have noticed the disk filling up. The other goes quiet and reopens like nothing happened. Both are back online by breakfast. Only one of them still has the people who were logged in when it broke.
You can't promise a server that never falls over, and anyone who does is either lying or hasn't been running one long enough yet. What you can promise is that within five minutes of it happening, somebody will be in the channel saying what's broken and when they'll speak next. That's a promise you can keep at 2:14am with one hand while the other is on the console.
The shed, meanwhile, remains unfinished. At least you'd know when I'll next talk about it.
