Understanding Rate Limits
Why does the bot sometimes slow down channel restoration during a big attack, even though it can detect and stop the attacker instantly? This page explains the limits Discord imposes on any bot, and why respecting them is what actually protects you long-term.
Why this matters specifically for your server
Discord bans the server's entire IP address (not just the bot) for up to a full hour if the volume of failed requests exceeds a certain threshold within 10 minutes. One bot serves thousands of servers from the same host — so if one server pushes past that threshold (say, from a violent attack), protection pauses for every other server too, not just yours. This is exactly what the deliberate pacing system prevents.
Types of limits Discord imposes#
| Type | Limit | What it means |
|---|---|---|
| Per-Route Limit | Varies by request type (e.g. creating a channel: one request every few seconds per server) | Doing the same action too fast on the same server gets temporarily rejected |
| Global Per-Token Limit | ~50 requests/second for the entire bot (all servers combined) | Exceeding it means the bot is serving a very large number of servers at once |
| Cloudflare Ban (IP-level) | 10,000 "invalid" requests (401/403/429) within 10 minutes | The most severe — bans the server's entire IP for up to an hour, halting everything for every server |
Why does speed differ between "stopping" and "restoring"?#
During a real nuke attack (deleting dozens of channels, say), the bot needs to perform two completely different kinds of actions:
- Stopping the attacker (kick, ban, strip permissions): a single action per attack, and it can't be delayed — every second of delay means one more deleted channel. So this action bypasses every queue and runs instantly, even under heavy network pressure.
- Restoring the damage (recreating 50 deleted channels, say): this is made up of dozens of consecutive requests. Firing them all at once means sending a large burst of requests to the same server within seconds — exactly the pattern that gets an IP banned by Cloudflare. So it's executed with a small delay between each channel and the next (usually under a second), which looks a bit slower but is completely safe.
What this means for you in practice
The attacker is always stopped within a fraction of a second. If 50 channels were deleted, expect them all back within a few seconds — not instantly at the exact same moment, which is a natural difference that's barely noticeable in most cases.
What happens if the executor can't be identified?#
Sometimes — especially under heavy network pressure or simultaneous suspicious activity (like re-adding the bot's integration) — identifying who performed a given action may be delayed or fail. The system is built on one clear principle:
Safety first, even without knowing the culprit
If the executor can't be identified, the bot still restores whatever was destroyed (channels or roles) — it never stops protecting just because attribution failed. The only difference is that an unidentified person can't be punished, so you'll see "Unknown executor" in the logs instead of a specific name, while restoration continues as normal.
What if a Cloudflare ban actually happens?#
In the rare case that pressure exceeds the limit, the bot automatically detects the ban and halts all outgoing requests for a few minutes until the ban lifts on its own — this behavior is automatic and safe.
Don't restart the bot during a ban
Restarting the bot during an active ban extends the ban instead of fixing it, because every new connection attempt counts as an extra request during the penalty window. If you notice unusual slowness, wait a few minutes — the bot recovers on its own.