GuidesOnly show guides for your app
GuidesGuidesWhen people start adding your bot everywhere, three things come due — Discord's verification gate, getting listed, and behaving under rate limits. A conservative checklist of the parts that are stable, with the numbers you can actually rely on.
Your bot works, and people want it in their servers. Growth is exciting, but it brings a few things you can't ignore: a hard verification gate from Discord, the mechanics of getting discovered, and the discipline to not get rate-limited into oblivion. This is a conservative checklist — the parts that are stable and worth planning around, without promises about traffic that nobody can make.
| At a glance | |
|---|---|
| You need | a working, deployed bot |
| Plan | any — though 24/7 uptime becomes more valuable as you grow |
| Time | a checklist to work through over time |
This is the big one, and it's Discord policy, not opinion. A bot can be added to servers freely up to a point — but once it reaches 100 servers, it must be verified to be added to more, and Discord grants privileged intents (Message Content, Server Members, Presence) to verified bots only, by approved request. You can apply for verification as you approach 75 servers. Verification means the owner completes identity verification and explains why the bot needs any privileged intents it requests.
Two things follow, and you should plan for them early:
🎯 Good to know: Discord owns these thresholds and can change the exact process. Treat "75 to apply, 100 to require" as the stable shape, but read Discord's current developer documentation before you apply for the up-to-date steps.
A single connection to Discord can only handle so many servers. At large guild counts, Discord requires your bot to shard — split its connection into pieces. You won't hit this early, and you don't hand-roll it: discord.js ships a ShardingManager that handles the split for you, and Discord's gateway tells your library how many shards it recommends. The honest takeaway: know sharding exists so it isn't a surprise, and turn it on when Discord tells you to — not before.
Bot lists are how most people discover bots. Prepare a good listing and submit to the well-known directories (top.gg, discord.bots.gg, discadia, and others):
bot and applications.commands scopes, and only the permissions your features use. Over-asking scares people off.Many lists can POST to a webhook when someone votes for you, which you can turn into a reward — hook it into your economy or leveling data. No list can promise you traffic, so treat listings as availability, not a growth strategy.
Discord rate-limits every route, and a well-behaved bot never trips them. The rules are simple:
| Do | Don't |
|---|---|
| Let your library's built-in request queue pace calls | fire hundreds of API calls in a tight loop |
| Cache data you already have | re-fetch the same user/guild repeatedly |
| Batch updates into one message | edit a message on every single event |
On a 429, wait the Retry-After and retry |
hammer the same request immediately |
Ignore these and you earn a global 429 — or worse, a temporary Cloudflare ban on your whole server's IP. See Discord rate limits.
At a handful of servers, a crash is a shrug. At hundreds, it's visible to everyone at once. Before you push for growth, make the bot boring and dependable:
| ✅ | Before you push for growth |
|---|---|
Token in .env, never in code or Git |
secrets |
| Only the intents and permissions you actually use | slash vs prefix |
| Slash commands, so you don't depend on Message Content | above |
| Errors caught; the process survives a bad command | error handling |
| Data backed up and migrations in place | migrations |
| Invite link with correct scopes/permissions | section 3 |
| Tested in a private server before shipping | test server |
| A plan for uptime | keeping apps online |