Paid Discord server outage: a playbook for the first hours
When a free server goes down, people wait. When a paid one goes down, they open chargebacks. This is the order of operations, and the messages, that keep subscribers on your side while RestoreCord brings the server back.
Short answer
Contain the attacker first, then restore a clean snapshot, pull verified subscribers back, run Restore Roles and re-sync your billing bot. Tell subscribers early, outside Discord, what happened and when paid channels return, and don't promise that every single member will be back.
The clock you're racing
For a paid community, an outage isn't a technical problem first. It's a trust problem. Subscribers who can't see what they pay for start asking questions within the hour, and silence turns questions into refund requests. The good news: if members verified through RestoreCord and you kept snapshots, the technical side is a sequence you can follow calmly. The communication side is what most owners get wrong.
Hour one: contain, then speak
If the server was nuked or an account was taken over, nothing gets restored until the attacker is out. Restoring into a live compromise just repeats the damage.
- Secure the owner account from a trusted device: new password, MFA checked, unknown sessions ended.
- Revoke unknown admin roles, integrations, webhooks and applications. Rotate any exposed bot token or API key.
- Write down what you see in the audit log, with times, before you change anything else.
- Post a first update to subscribers outside Discord.
That first update should be short and specific. Something like:
Gold Lounge is down after a security incident on our staff side. Your subscription is safe and nothing is being charged twice. We're rebuilding from last night's backup and expect paid channels back today. Next update in two hours.
Hours two to six: rebuild in the right order
The order is fixed for a reason. Each step depends on the one before it:
Secure owner, revoke access, rotate tokens
Channels, roles, permissions, messages
Prior-authorized members only
Re-assign saved roles to members who returned
Staff first, then the community
| Step | What you do in RestoreCord | Depends on |
|---|---|---|
| Restore | Pick a snapshot from before the first malicious change and restore it | Contained access |
| Pull | Pull verified members from your member database, with a role on join | Rebuilt server and bot permissions |
| Re-tier | Start Restore Roles from the Pending Role Restore banner | Members already in the server |
| Re-sync | Reconnect the subscription bot for roles it manages | Restored roles |
The newest snapshot isn't always the right one. If the attacker had access for a while, choose the last backup from before their first change. This is where a pinned, trusted snapshot pays for itself. The details of the third step are in our guide to restoring paid subscriber roles.
Report honest numbers
A pull can only add members who verified before the incident and haven't revoked access, and Discord can still refuse individual adds. So don't tell subscribers that "everyone is back" because the progress bar finished. Track outcomes separately: succeeded, already present, skipped, ineligible and failed. Then tell the people who couldn't be added how to rejoin, through your store or mailing list.
Never post your pre-incident member count as "recovered". Subscribers who weren't pulled will notice, and the gap becomes the story.
Reopen in stages
Let staff in first and check permissions on every paid category. Then open to a small group of subscribers, then everyone. Watch the audit log between stages. When it's stable, take a fresh snapshot and pin it, so the next incident starts from today rather than last month.
Make the next outage shorter
Every hour above was faster because of work done earlier: verification in front of the paid tier, scheduled snapshots on Business, and a practice pull into a test server. If you haven't done those yet, start with keeping paying members recoverable, consider buyer-only verification, and see the full picture on RestoreCord VIP.
Before you tell subscribers it's over
Tick these off in order. If one is open, the outage isn't finished yet.
Owner account locked down
Password changed from a trusted device, MFA confirmed, unknown sessions ended.
Rogue access removed
Unknown admin roles, webhooks and integrations revoked; exposed bot tokens rotated.
Clean recovery point chosen
A snapshot from before the first malicious change, not automatically the newest one.
Structure restored
Channels, roles and paid categories rebuilt and checked against your tier design.
Subscribers pulled back
Outcomes tracked as succeeded, already present, skipped, ineligible or failed.
Tier roles re-applied
Restore Roles finished and the skipped list handled by hand or by your billing bot.
Fresh snapshot taken
A new pinned backup of the stabilised server, so the next incident starts from today.
Subscribers told it's over
A closing update with what changed and what you're doing so it doesn't happen again.
Subscriber communication questions
The best outage plan is one you never improvise
Verify subscribers, schedule snapshots and rehearse a pull with RestoreCord while everything is still calm.