Your bot crashed at four in the morning and the console has scrolled past. Logging is the difference between «it broke again» and «it broke at 04:12 in the ticket command, on this input» — and it is about ten minutes of work, once.
Getting from nothing to useful
- Catch what currently dies silently
In Node,
process.on("unhandledRejection", console.error)andprocess.on("uncaughtException", console.error). In Python, wrap your entry point and log the exception. Silent deaths become reasons. - Write to a file, not only to the console
The console is a live view that vanishes. A file in your bot's directory is still there tomorrow, which is when you will actually look.
- Put a timestamp on every line
«An error» is not useful. «An error at 04:12» can be matched against a restart, a Discord outage, or the moment someone ran a command.
- Log at the boundaries
When a command starts, when an external call returns, when something is written. The middle of your code rarely needs a line; the edges always do.
A debug line that prints your config prints your token, and that log file may end up in a support ticket or a screenshot. The same applies to message content and user identifiers — log what you need to debug, not everything you happened to have in a variable.
What is worth logging
| Event | Log it? |
|---|---|
| Startup and successful login | Yes. It timestamps every session. |
| Every command invocation | On a small bot yes; on a busy one it becomes noise. |
| Every error, with its stack | Always. |
| External API calls that failed | Yes, with the status code. |
| The content of every message seen | No. Volume and privacy both argue against it. |
A bot logging every event writes continuously. Either use a logging library that rotates daily, or truncate the file on a schedule. Discovering a log file has filled your disk is a preventable way to lose an evening.
Cause a deliberate error, restart the bot, and confirm the log file still contains it with a timestamp.