How to keep a Discord bot online 24/7

Why does a Discord bot go offline?

A bot is online only while a program you wrote is running and holding an open WebSocket connection to Discord's gateway; the moment that process stops, the green dot disappears. Discord does not host your code. Your bot is just a client that logs in with a token, listens for events and responds to them, so it depends entirely on the machine and the process running it.

The usual causes are predictable. A home computer sleeps, reboots for updates or loses its internet connection. Closing the terminal window ends the process. An unhandled error crashes the bot and nothing starts it again. The system kills it for running out of memory. Or the bot never connects at all because its token was reset or it requests an intent that is not enabled in the Developer Portal, which Discord rejects with close code 4014.

Why don't free hosts keep a bot online?

Most free platforms are built for web apps that wake up when an HTTP request arrives, and they suspend anything that sits idle. A Discord bot does not receive HTTP requests; it opens its own outbound connection and waits for events, so to the platform it looks idle and gets put to sleep. The popular workaround, adding a tiny web server and pinging it every few minutes from an outside monitor, is fragile and often breaks the platform's terms.

Shared infrastructure adds a less obvious problem. Discord temporarily restricts IP addresses that make too many invalid API requests, currently 10,000 per 10 minutes, and on a free platform your bot shares its outgoing IP with many other people's projects. If one of them misbehaves, your bot can be cut off from the API as well. Free tiers are fine for experiments, but not for a bot a community relies on.

Where should you host a bot: home PC, VPS or bot hosting?

For a bot that must stay up, the real choice is between a VPS you manage yourself and managed bot hosting; a home machine only works if you accept occasional downtime. A gateway bot needs no open ports and no static IP, because it only makes outbound connections to Discord. What it does need is a machine that never sleeps, a stable connection and enough memory for the library's caches.

TheCrewHost offers both paths from İstanbul. Discord bot hosting runs Node.js (discord.js) and Python (discord.py) bots around the clock with npm and pip support, a file manager and free DDoS protection. A KVM-based VPS gives you full root access to run your bot, its database and a web dashboard side by side.

How do pm2 and systemd keep a bot running?

A process manager starts your bot in the background, restarts it when it crashes and brings it back after a server reboot, which is exactly what 24/7 uptime requires. pm2 is the common choice in the Node.js world and can run Python scripts too. pm2 start index.js --name mybot launches the bot, pm2 save stores the process list, and pm2 startup prints the one command that registers pm2 with the system's init system; run it, and your bot comes back on its own after every reboot.

systemd, built into most modern Linux distributions, does the same job without extra software. You write a small unit file that sets the user, the working directory and the ExecStart command, add Restart=on-failure with a RestartSec delay, and enable it with systemctl enable --now. Output goes to the system journal, where journalctl -u followed by the service name shows it.

Whichever you pick, put a delay between restarts. A bot stuck in a crash loop logs in again on every restart, and Discord allows 1,000 gateway logins (IDENTIFY calls) per 24 hours across all shards. Go over that and Discord terminates every session and resets your token. pm2's --exp-backoff-restart-delay option and a sensible RestartSec in systemd prevent it.

How do you keep your bot token safe?

Treat the token like a password: anyone who has it can log in as your bot and use every permission the bot holds. Never write it into your source code, never commit it to Git and never print it in logs or error messages. Put it in an environment variable instead and have your code read it at startup, for example with process.env.DISCORD_TOKEN in Node.js or os.environ in Python.

The usual pattern is a .env file next to the code, listed in .gitignore and readable only by the bot's user (chmod 600). Node.js 20.6 and later can load it natively with node --env-file=.env, older setups use the dotenv package, and Python bots use python-dotenv. Under systemd, an EnvironmentFile line does the same, and pm2 can read variables from its ecosystem file, which then has to stay out of Git as well.

If a token ever leaks, reset it on the Bot page of the Developer Portal right away. The old token stops working at once, and the new one is shown only once, so save it before you close the page. When you generate the invite link, grant the bot only the permissions it needs, which limits the damage any leak can do.

discord.js vs discord.py: what changes when you host them?

Both libraries keep a bot connected the same way, so hosting differs mainly in the runtime and in how dependencies are installed. discord.js runs on Node.js: dependencies are declared in package.json, installed with npm, and the bot connects with client.login. On a server, npm ci installs exactly the versions recorded in package-lock.json, which keeps production identical to what you tested.

discord.py runs on Python and connects with bot.run. Install its dependencies from requirements.txt into a virtual environment rather than the system Python; recent Debian and Ubuntu releases block system-wide pip installs by default anyway. When you run it under pm2 or systemd, point to the Python binary inside that virtual environment so the right packages load.

Before upgrading, check each library's README for the minimum runtime version, because new major releases raise it. Both libraries also cache data such as members and messages in memory. discord.py keeps up to 1,000 messages by default, and discord.js lets you limit caches and sweep out old entries through the client options. Tuning caches is the easiest way to keep a growing bot within a small plan's RAM.

Which gateway intents does your bot actually need?

Intents tell Discord which events to send your bot, and you should request only the ones your features use, because every extra intent means more events to process and more data to cache. Three intents are privileged: server members, presence and message content. They must be switched on under Privileged Gateway Intents on the Bot page of the Developer Portal before your code requests them. Otherwise the connection closes with code 4014, which libraries report as a disallowed intents error.

Message content is the one most bots trip over. Without it, message content arrives empty, except in direct messages, messages that mention the bot, the bot's own messages and messages used with a context menu command. Slash commands do not need it at all, which is one good reason to move prefix commands over to slash commands. Once an app reaches more than 10,000 users, Discord also requires a review to keep access to privileged intents.

When does a Discord bot need sharding?

Sharding splits a bot's servers across several gateway connections. A single shard can handle at most 2,500 servers, so Discord requires sharding once a bot reaches 2,500. The discord.js guide suggests preparing at around 2,000 servers and planning for roughly 1,000 servers per shard, and Discord's gateway bot endpoint returns a recommended shard count for your bot.

In discord.js, the ShardingManager runs each shard in its own process, while the shards: 'auto' client option keeps them all in one process, which the guide warns becomes memory-heavy for big bots. discord.py offers AutoShardedClient and AutoShardedBot, which manage shards for you inside a single process. Because all shards share the 1,000 logins per day and a max_concurrency value limits how many can start at once, restart large bots in rolling batches rather than all at once.

How do you log and monitor a bot?

Logs tell you why a bot went down, and monitoring tells you that it did. Send output to the process manager's logs, read them with pm2 logs or journalctl, and add log rotation, for example the pm2-logrotate module, so files never fill the disk. Log the events that describe the connection: ready, disconnects, resumed sessions and errors. In Node.js, also log unhandled promise rejections, which crash the process by default.

Track a few numbers over time: memory use, restart count and gateway latency, which both libraries expose as a ping or latency value. Remember that on_ready in discord.py can fire more than once after reconnects, so keep one-time setup out of it. For alerts, use a heartbeat check: the bot reports to an external monitor every minute, and you get notified as soon as the reports stop.

How do you update a bot without taking it offline?

A gateway bot cannot swap processes with literally zero downtime, but a well-planned restart shrinks the gap to a few seconds. Do the slow work first: pull the new code, run npm ci or pip install and run your tests while the old version is still online, then restart once. Never start the new version next to the old one with the same token, because both copies receive every event and your bot answers everything twice.

Some changes need no restart at all. discord.py extensions (cogs) can be reloaded with reload_extension, and discord.js bots can reload command modules at runtime. Register slash commands with a separate deploy script only when their definitions change, not on every startup. Sharded bots can restart shard by shard, and bots that only use slash commands can receive interactions over HTTP instead of the gateway, which lets you deploy them behind a load balancer like any other web app.

How to run a Discord bot 24/7 on a Linux server

1. 1

   Prepare the server

   Update the system, create a separate non-root user for the bot and install a current Node.js LTS release or Python 3 with venv, depending on your library.

2. 2

   Upload the code without secrets

   Clone your repository or upload the files over SFTP. Make sure the .env file and anything else containing the token stay out of Git.

3. 3

   Install dependencies

   Run npm ci for discord.js, or create a virtual environment and install requirements.txt for discord.py. Fix any errors now, before the bot runs as a service.

4. 4

   Store the token as an environment variable

   Create a .env file readable only by the bot's user, or an EnvironmentFile for systemd, and read the token from it in your code.

5. 5

   Check intents in the Developer Portal

   Enable only the privileged intents your code requests, then run the bot once in the foreground to confirm it logs in and answers a command.

6. 6

   Put it under a process manager

   Start it with pm2 using an exponential backoff restart delay, or create a systemd unit with Restart=on-failure and a RestartSec delay.

7. 7

   Make it survive reboots

   Run pm2 save and the command printed by pm2 startup, or systemctl enable for your unit. Reboot once to prove the bot comes back on its own.

8. 8

   Set up logs and alerts

   Turn on log rotation, watch memory use and restart counts, and add a heartbeat monitor that alerts you when the bot stops checking in.

Frequently Asked Questions