How to keep a Discord bot online
“Online” means your process is running, connected to Discord’s gateway, and able to respond within acceptable latency. This article covers practical causes of downtime and how to design for recovery on shared hosting.
Measure the right thing
Discord shows a green dot when the gateway session is alive. Users care whether commands respond. Those can diverge: a process might be connected but stuck on a blocking call. Use logging around command handlers and consider a simple health command that reports process uptime and latency to the WebSocket.
Unhandled errors
An exception in an event handler can take down the entire process if you do not handle it. In Node, register listeners for unhandledRejection and validate async handlers. In Python, ensure exceptions in listeners are logged. Never assume “Discord.js will catch it.”
Memory growth
Caches that never expire, unbounded message collectors, and growing arrays are common on long-running bots. Free plans with 512 MB–1 GB RAM will OOM-kill processes that leak. Periodically review what you store in memory; prefer Redis or a database for large state if the host allows it.
Dependency and runtime updates
Host image upgrades change Node or Python versions. Pin major versions intentionally and read library changelogs. After panel-side updates, restart and watch console output for deprecation or API errors.
Network blips
Gateway libraries reconnect automatically, but custom code that assumes a permanent connection may fail. On resume, re-register application-level state if needed. Avoid tight reconnect loops that trigger rate limits.
Hosting-layer restarts
Hosts restart nodes for maintenance. Free tiers may stop idle or unverified servers. Read your provider’s offline and verification policies. Design startup to be idempotent: the bot should become useful after a cold start without manual console commands.
Operational habits that help
- Keep a runbook: how to rotate the token, where logs live, how to roll back files.
- Use meaningful log levels; debug spam hides real crashes.
- Stage changes on a development application before production.
- Monitor disk: full disks cause cryptic write failures.
When to move off free hosting
If you need multi-bot fleets, inbound webhooks, dedicated resources, or contractual uptime, free shared pools are the wrong tool. Paid bot hosting or a small VPS with process supervision (systemd, Docker restart policies) is the next step. CogitHost’s free tier is aimed at learning and community utility bots within published limits—see choosing free bot hosting.