Why trust this guide
By Victus Cloud · Reviewed by Victus Cloud · No individual author claimed. Verify paths, versions, and backups before changing a live service.
Evidence-led, product-agnostic
Always-on is a design, not a wish
Most bot outages are not caused by the hosting provider. They are caused by a process that was started in a terminal, crashed on an unhandled exception, and never came back. Hosting gives you a machine and power; it does not guarantee your code keeps running. Treat 'always online' as an explicit engineering requirement: something must supervise the process, capture why it died, and restart it on a sane schedule. 'It worked on my laptop' is a development story, not a deployment plan.
A useful mental model is that the bot process, the runtime, the host, and the Discord gateway are four separate things that can each fail independently. Your job is to make the failure of any one of them as boring as possible. The rest of this guide builds that resilience layer by layer, from how the process is launched to how you learn that it stopped responding.
Plan resources and controls vary
Whether a product exposes always-on processes, scheduled tasks, custom runtimes, outbound network access, or specific ports depends on the current plan. Verify the panel and product before promising a specific bot architecture to your community.
Run it under a process manager
A bare node bot.js or python bot.py in a shell survives only as long as that shell stays open. A process manager decouples the bot from your login session and adds restart and logging behavior. On a self-managed VPS you might use systemd, pm2, or supervisord. In a container, the container runtime or an init process provides similar guarantees. The important part is not which tool, but that the bot restarts on failure, starts on boot, and writes its output somewhere you can read later.
- Restart on non-zero exit, but use a small delay or backoff so a crash loop does not hammer the gateway.
- Capture stdout and stderr to a rotated log file so a crash is diagnosable, not a mystery.
- Set memory and CPU limits so a runaway bot cannot starve everything else on the host.
- Keep the bot as a non-root user where possible; a compromised bot should have minimal reach.
- Separate configuration from code through environment variables rather than hardcoded constants.
[Unit]
Description=Discord bot
After=network-online.target
Wants=network-online.target
[Service]
User=botuser
WorkingDirectory=/srv/bot
EnvironmentFile=/srv/bot/.env
ExecStart=/usr/bin/node bot.js
Restart=on-failure
RestartSec=5
MemoryMax=512M
[Install]
WantedBy=multi-user.targetThe example above is a starting shape, not a copy-paste solution. Real units need correct paths, a dedicated user, and a hardened EnvironmentFile permission set (mode 600, owned by the service account). On managed bot hosting, prefer the panel's documented start command and log viewer over hand-rolling a supervisor you cannot see.
Choose a runtime and host that match the bot
Discord bots are commonly written in JavaScript/TypeScript (discord.js) or Python (discord.py and successors), but the gateway and REST APIs are language-agnostic. Pick the stack your team can actually maintain. A heavier bot with slash commands, audio, and background jobs needs more memory than a tiny moderation helper; size the plan after measuring the bot idle and under load, not before. A bot that holds many guilds in memory can use surprising amounts of RAM as the guild count grows.
| Signal | Why it matters | Cheap check |
|---|---|---|
| Resident memory | Grows with cached guild/channel state | Watch the process manager limit and RSS over a week |
| Gateway reconnects | Signals network or resume-token problems | Count reconnect events in logs |
| REST 429s | You are exceeding rate limits | Log response headers and back off |
| Event-loop lag | Slow handlers delay every event | Measure time between event and handler start |
| Startup time | Slow boot delays recovery after crash | Time a clean restart during maintenance |
Separate configuration from code
Configuration that lives in code gets committed, copied, and forgotten. Configuration that lives in the environment can differ per deployment without touching the source. Keep guild IDs, feature flags, log levels, and external service URLs in environment variables or a secrets file mounted at runtime. This also makes rollbacks safer: you can redeploy old code with the current configuration, or change a flag without a new release.
- Define every setting your bot reads and give each a sane default where possible.
- Load settings at startup and fail loudly if a required value is missing.
- Keep secrets in the environment file, never in the repository or in logs.
- Document each variable so a new operator can reproduce the deployment.
- Use a separate environment for testing so a bug in staging cannot touch production guilds.
Handle tokens like passwords
A Discord bot token is effectively a password that lets someone act as your bot. Store it in an environment file outside the repository, never commit it, and rotate it the moment you suspect exposure. A leaked token can be used to send messages, join servers, or read what your bot can see, so treat any leak as a real incident. If you use a public repository, scan for accidental commits and add a pre-commit check.
A logged token is a leaked token
Debug output that prints the full environment, full connection URL, or Authorization header can expose your token to anyone who reads the logs. Redact secrets before sharing logs with support or in issue trackers.
Prefer a secrets manager or the hosting panel's secret store over a plaintext file when available. If you must use a file, restrict it to the service account and exclude it from backups or rotate the token after any backup that may have included it. Rotation should be a calm, rehearsed step, not a panic response.
Plan for graceful updates
Editing live files on a running bot is how outages happen. Deploy with a documented restart step, keep a previous known-good build, and avoid random in-place edits. A clean release flow is: pull the new code to a staging environment, run a quick smoke test, then roll forward on production with the supervisor handling the restart. If the new version fails, the supervisor should be able to fall back to the prior build through your own release process.
- Tag releases so you can identify exactly what is running.
- Run database or schema migrations as an explicit, backed-up step.
- Keep a previous build directory you can symlink back to on failure.
- Announce maintenance windows for breaking changes that affect commands.
- Verify the bot re-identifies to the gateway after restart rather than assuming it did.
Handle reconnects and rate limits deliberately
The Discord gateway can drop connections for routine reasons, and the REST API enforces rate limits with HTTP 429 responses. A bot that ignores these will reconnect in a tight loop or spam requests and get limited harder. Use a maintained library that implements resume, heartbeat, and backoff correctly rather than writing your own gateway client. When you do call REST, respect the Retry-After header and the per-route limits; batch work and cache where you can.
heartbeat ack received
gateway resumed session 12345
replaying 2 missed eventsIf you see repeated 'connect, identify, drop' cycles, the cause is often an invalid token, a session that was killed by a second login with the same token, or a network path that resets connections. Two processes using the same token will fight each other; never run the same bot token from more than one place in production. Use sharding when a single connection cannot hold all your guilds, and let the library manage the shard count.
Monitor what actually tells you the bot is alive
A process that is 'running' can still be dead to users if it has lost the gateway. Monitor from outside the process: an external heartbeat that checks the bot responds to a command, a watchdog that watches the gateway socket, and alerting on reconnect storms. Pair this with host metrics (memory, CPU, disk) so you notice slow leaks before they become crashes. An external check is valuable because if the whole host hangs, an in-process monitor cannot report.
A calm incident checklist
- Confirm the symptom: is the bot offline for everyone, or only one guild or user?
- Check the process manager and recent logs for the first error, not the last cascade.
- Check the status page for a platform incident before assuming it is your code.
- Verify the token was not reset or leaked; rotate it if you cannot account for it.
- Restart once through the supervisor with a backoff; do not reboot in a panic loop.
- If it recovered, write down the cause and the change; if not, open a support case with logs.
Reliable bot hosting is mostly boring discipline: supervise the process, protect the token, respect the gateway, and watch from outside. Do those and the exciting failures become rare, and the remaining ones are easy to explain.