Logging and monitoring your Discord bot: know about problems before members do

A bot that quietly stops working is worse than one that visibly crashes. Members notice when commands stop answering, long before you do, unless you have some way to know. Good logging tells you what happened, and monitoring tells you when. Neither takes much effort to set up, and together they turn mysterious outages into short, fixable ones.

What to log

A log is a diary your bot writes about itself. The aim is that when something goes wrong, you can read back and see what led up to it.

Worth recording:

• Start-up and shutdown, including which version of your code is running.
• Connection events: connecting, reconnecting, disconnecting and the reason.
• Errors, with the full stack trace and what the bot was doing.
• Commands run, with the command name, the server ID and the user ID. Not the content of private messages.
• Slow operations, such as commands that took more than a couple of seconds.
• Rate limit warnings, which signal bad behaviour. See How to handle Discord rate limits.

What not to log

• Your token or any secret. Logs get shared when you ask for help, so a leaked secret in a log is a leak. See Environment variables and keeping your bot token safe.
• Private message content and sensitive personal information. Log that something happened, not the private details.
• Every single message on a busy server, unless you have a reason. It floods the log and uses disk space.

Levels

Use levels so you can turn detail up or down:

Level	Use for
DEBUG	Detailed information, for finding a bug
INFO	Normal events, such as start-up and commands
WARNING	Something odd, but handled
ERROR	Something failed
CRITICAL	The bot cannot continue

Run at INFO normally, and switch to DEBUG temporarily when you hunt a problem.

Setting it up

In Python, use the built-in logging module:

import logging
logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(name)s: %(message)s")

discord.py also logs through this system, so you will see its connection messages too.

In Node.js, a small library such as pino or winston gives you levels and timestamps. At minimum, include a timestamp in every line, because a log without times is hard to use.

The console shows the output live, which is enough to start with. To keep history, also write to a file, such as logs/bot.log, and download it with the file manager when needed.

Stop logs filling the disk

A log file that grows forever will eventually fill your disk and take the bot down. Use rotation: start a new file each day, or when a file reaches a size limit, and keep only the last few. Both Python and Node loggers support this. Check your disk use from time to time, as described in What the CPU, memory and disk numbers on your server mean.

Catch errors everywhere

Unhandled errors can crash the bot or vanish silently. Add handlers that log them:

• In Node.js, handle unhandledRejection and uncaughtException, and the client's error event.
• In Python, wrap command handlers in try and except, and implement the library's error event, so a failure in one command is logged and does not stop the bot.

See Keep your bot online for more on this.

Monitoring: knowing it is up

Logs help after the fact. Monitoring tells you now.

Watch the basics. Your panel's graphs show memory and CPU. A memory line that climbs steadily without dropping is a sign of a leak. A CPU line stuck high points to a loop.

Check the connection. Libraries expose the delay to Discord, called latency or ping, such as client.ws.ping in discord.js and bot.latency in discord.py. A sudden jump or a value that stops updating is a warning sign. Make a /status command that shows it, along with uptime and the code version.

Alert yourself. Have the bot send a message to a private channel, through a webhook, when it starts, when it crashes or when it reconnects often. Even simpler, send a message at start-up: if it keeps arriving, the bot is restarting in a loop.

Use an outside check. If your bot runs a small web endpoint, a free uptime-monitoring service can poll it every few minutes and message you when it fails. This catches the case where the whole server is down, which an internal alert cannot report.

A simple monitoring set

1. A start-up message in a private channel.
2. A /status command.
3. An alert on crashes.
4. A weekly look at memory and disk.

That is enough for most bots.

Using the log to fix things

When something breaks, read the log from the first error, not the last. The first is usually the cause, and the rest are consequences. How to read your server logs has detailed advice. Keep notes of problems and what fixed them. In time, you will recognise patterns quickly.

---

Still stuck? Open a ticket on Discord - run /ticket in any channel, pick a department, and include your Server ID or Invoice ID so we can jump straight in.