# Logging Is Not Debugging

- Link: https://dev.ejohnny.ro/logging-is-not-debugging/
- Published: 2026-10-19T09:21:16+03:00
- Author: eJohnny

When something breaks in production, the first instinct is to add `console.log` 
statements everywhere, redeploy, and wait for the error to happen again. That is
not debugging. That is guessing with extra steps.

Logging and debugging are different tools for different jobs. Confusing them makes
problems harder to find, not easier.

![Hands typing on a laptop with code on screen](https://images.unsplash.com/photo-
1756830231350-3b501f63c5c1?fm=jpg&q=60&w=1200&auto=format&fit=crop)

Hands typing on a laptop with code on screen. Photo by Rahul Mishra on Unsplash.

## What debugging actually is

Debugging is the process of finding the root cause of a bug. You reproduce the issue,
inspect the program state, trace the execution, and identify exactly where the logic
went wrong. A debugger lets you pause execution, examine variables, and step through
code line by line.

Logging is just recording what happened. It does not find the bug for you. It gives
you breadcrumbs.

## Why console.log everywhere fails

Adding print statements to every function creates noise, not signal. In production,
you get flooded with output. You cannot tell which log line matters. Worse, you 
often forget to remove them, shipping debugging code to real users.

If the bug does not happen while you are watching, your logs do not help. You have
to reproduce it, add more logs, redeploy, and wait again. That is a slow, expensive
loop.

## What good logging looks like

Good logging answers three questions without requiring a redeploy:

 * What happened?
 * When did it happen?
 * Which request, user, or input triggered it?

Use structured logging — JSON output with fields like `level`, `timestamp`, `service`,`
request_id`, and `message`. This makes logs searchable and filterable.

Example of a bad log:

    ```
    User logged in
    Value is 42
    Error happened
    ```

Example of a good log:

    ```
    {"level":"error","timestamp":"2026-01-15T10:32:01Z","service":"auth","request_id":"abc123","message":"login failed","reason":"invalid credentials","user_id":null}
    ```

## When to use each

 |  Situation |  Tool |  
 |  Reproducing a bug locally |  Debugger / breakpoints |  
 |  Understanding production failures |  Structured logs |  
 |  Tracking request flow across services |  Correlation IDs in logs |  
 |  Quick check during development |  Console.log (temporary) |

## The rule

Debug locally with a debugger. Monitor production with logs. Do not use logs to 
debug locally, and do not rely on a debugger in production.

Console.log is a crutch. Logging is infrastructure.

### Share this:

 * [  X ](https://dev.ejohnny.ro/logging-is-not-debugging/?share=twitter)
 * [  Facebook ](https://dev.ejohnny.ro/logging-is-not-debugging/?share=facebook)
 * [More](https://dev.ejohnny.ro/logging-is-not-debugging/#)

 * [  LinkedIn ](https://dev.ejohnny.ro/logging-is-not-debugging/?share=linkedin)
 * [  Reddit ](https://dev.ejohnny.ro/logging-is-not-debugging/?share=reddit)
 * [  Tumblr ](https://dev.ejohnny.ro/logging-is-not-debugging/?share=tumblr)
 * [  Pinterest ](https://dev.ejohnny.ro/logging-is-not-debugging/?share=pinterest)
 * [  Telegram ](https://dev.ejohnny.ro/logging-is-not-debugging/?share=telegram)
 * [  WhatsApp ](https://dev.ejohnny.ro/logging-is-not-debugging/?share=jetpack-whatsapp)