Engineering · · 4 min read
Hosting a Discord Bot in Production: Uptime, Rate Limits and Sharding
By N3XT Agency
Why a bot that runs fine on a laptop falls over in production — and the hosting, restart, rate-limit and sharding decisions that keep one online around the clock.
Most Discord bots are written on a laptop and deployed by leaving that laptop on. It works until the first reboot, the first network drop or the first busy evening. Running a bot properly is not difficult, but it is a different job from writing one, and most outages we are asked to fix come from the running, not the code.
Two ways a bot hears from Discord
A classic bot holds a WebSocket connection to Discord's gateway and receives events — messages, joins, reactions — as they happen. That connection has to stay open around the clock, which means the bot is a long-running process that needs somewhere to live: a small virtual server, a container platform or a managed bot host.
A bot that only responds to slash commands, buttons and modals can skip the gateway and receive interactions as HTTP requests instead. That makes it a web endpoint, which can run on serverless platforms and costs almost nothing when idle. The trade-off is that it only wakes when someone interacts with it; anything that must react to events on its own — welcome messages, moderation, logging — still needs the gateway.
Keep the process alive
A gateway bot will crash eventually: an unhandled error, a library bug, a host restart. Production hosting means something restarts it automatically. On a server that is a process supervisor such as systemd or a container runtime with a restart policy; on a platform it is usually built in. Test it by killing the process on purpose and watching it come back.
Just as important is not restarting too eagerly. Every restart re-identifies with the gateway, and a bot stuck in a crash loop can hit Discord's session start limits and lock itself out for a while.
Respect the rate limits
Discord allows each bot up to fifty API requests per second globally, plus per-route limits that vary by endpoint. The mainstream libraries queue requests to respect these for you, which is a strong reason to use one rather than calling the API by hand.
The limit that takes bots offline is a different one. IP addresses that make too many invalid requests — responses with status 401, 403 or 429 — are temporarily blocked from the API by Cloudflare. The current threshold is 10,000 invalid requests in ten minutes. A bot that keeps retrying with a revoked token, or keeps trying to post in a channel it lost access to, can reach that surprisingly quickly — and on shared hosting, other people's bots on the same IP count too.
Answer interactions in time
Every slash command and button press must be acknowledged within three seconds. A bot on an overloaded host, or one that queries a slow database before replying, misses that window and the member sees "The application did not respond". Defer first, then do the work: a deferred response buys fifteen minutes to send the real answer as a follow-up.
Sharding, when you need it
Each gateway connection — a shard — can serve at most 2,500 servers, and Discord requires bots in more than that to shard. Libraries handle the mechanics, but sharding changes the architecture: state that lived in one process is now split across several, so anything global, such as a cross-server leaderboard, has to live in a shared database or cache. If a bot is meant for public listing, design for this before it is needed.
Secrets and deploys
The bot token is a password to everything the bot can do. Keep it in an environment variable or a secrets manager, never in the repository, and rotate it immediately if it ever leaks — Discord and GitHub both scan for leaked tokens, but by then someone may already have used it.
Deploy from version control, not by copying files. It gives you a history of what changed and a one-command way back when a release misbehaves. Register slash commands as part of the deploy, not on every start, to avoid wasting requests.
Know when it is down
The worst way to learn your bot is offline is from a member. At minimum, log errors somewhere you will read, and use an external uptime check that alerts you when the bot stops responding. A daily heartbeat message in a private staff channel is a crude but effective version of the same idea.
What good hosting costs
For a bot serving one community, reliable hosting is inexpensive — the cost of a small virtual server or a basic managed plan. The expensive part is the attention: updates, monitoring and fixing what breaks. That is why we bundle hosting with maintenance rather than selling it as bare compute: an always-on bot is only useful if someone is watching it.
Sources
- Rate Limits — Discord Developer Documentation
- Gateway — Discord Developer Documentation
- Receiving and Responding to Interactions — Discord Developer Documentation
- My Bot is Being Rate Limited — Discord Developer Support