Log Judiciously

Judiciously: With good judgement. 

Logging is one of the simplest things a developer can do, and one of the easiest things to get wrong. A single misplaced log line can be harmless, but a pattern of careless logging turns into noise, confusion, and even security risk. 

The challenge isn’t teaching engineers how to log, it’s helping them understand why they’re logging in the first place. Here I intended to draw that distinction clearly: choosing logs that illuminate behaviour, support debugging, and reveal failures, while avoiding the chatter, duplication, and reassurance‑driven messages that bury the real signals.

Finding the Line Between Useful and Noisy

Teams often fall into the trap of believing that if they simply “log enough,” the rest of observability will take care of itself. It’s an appealing idea: produce a steady stream of detail, let dashboards and alerts sift through it, and assume that somewhere in the noise the truth will reveal itself. But this mindset skips the most important question in logging: 

What is the log for? 

Without a clear purpose, logging drifts toward reassurance rather than insight, verbose INFO messages that make the system feel busy, rather than meaningful events that help you understand behaviour, diagnose failures, or trace decisions. The challenge isn’t generating more detail; it’s choosing the right detail, at the right moments, for the right reasons.

This is where most teams go wrong. They treat logging as a comfort blanket rather than a diagnostic tool. They log because it feels good, not because it’s useful.

Your goal is not to create a diary of everything the service ever did. Your goal is to create a durable trail of evidence that explains what happened, why it happened, and how to fix it when it breaks. Logging is:

The deliberate recording of structured, time‑ordered information about what the service is doing and why

and not a stream‑of‑consciousness printout.

So let’s draw the line clearly.

1. Log What Helps You Fix Problems, Not What Makes You Feel Good

A good log tells you something meaningful about the system’s behaviour, and it should be:

• Succinct
• Useful
• Unique

A bad log tells you the system is alive and doing things, but nothing more. Compare these examples:

Useful:

Failed to process order 123456: Database timeout

This is actionable. It tells you what failed, why, and which business entity was affected. 

Useless:  

Order processed successfully

Without an identifier, this is noise. Without a reason to exist, it’s noise. Without a purpose, it’s noise. It’s just a warm fuzzy feeling that your system is running.

Actively harmful:

Something went wrong!  

This is the logging equivalent of shrugging.

The question to ask yourself is simple:  

If this log line disappeared tomorrow, would anyone struggle to diagnose an issue?

If the answer is no, it’s not worth logging.

2. INFO Logs Are Not a Substitute for Observability

INFO logs are the most abused level in the stack. Developers often use them as a heartbeat: 

• The user clicked a button
• The service started a loop
• We reached line 42

This is the warm fuzzy feeling problem.

INFO logs should describe meaningful business events, not internal chatter. INFO logs should be normal, expected events that confirm the system is working as intended. That means:

Good INFO:

Order 123456 processed successfully.  

This log message is a real business outcome. However, if you have high order throughput, this sort of log message would soon become noise.

Bad INFO:  

  Starting to process order…  
  Still processing order…  
  Finished processing order…

This sort of logging will quickly fill up your logs and provides no real value once you have confidence in your new feature or system. If you need this level or reporting going forward use traces, spans, and metrics. If you do put this level of logging in to gain confidence, remember there’s nothing stopping you taking it out afterwards or reducing it to DEBUG or even TRACE at the very least.

3. But Long‑Running Tasks *Do* Need Reassurance

There are exceptions, and they matter.

If a task runs for seconds, minutes, or hours, you need a way to know:

• It started  
• It’s still running  
• It completed  
• It failed  

This isn’t just for the warm fuzzy reassurance, this is operational visibility.

For example:

• A statement generator
• A batch job
• A reconciliation process

would be black boxes without periodic signals, but even here, the rule holds:

Log milestones, not heartbeat spam

Good:  

Statement generation started for 12,482 accounts.
Statement generation 40% complete (4,992/12,482).
Statement generation completed in 3m12s.

Bad:  

Processing account 1…
Processing account 2…  
Processing account 3…  

If you absolutely must have this level of logging, it belongs in DEBUG or TRACE, and should be in addition to the good info logs.

4. Errors Need Context - Always

When something breaks, the log must contain everything needed to diagnose it without digging through code or reproducing the issue.

All the details that appear in the concise human readable message should also be present in the structured context ensuring everything needed for debugging is captured reliably. That means:

• Business identifiers (orderId, userId, etc.)  
• Correlation IDs  
• Instance/pod identifiers  
• Error type  
• Error message  
• Stack trace  

If an ERROR log doesn’t tell you what failed, why it failed, and where it failed, it’s not an error log, it’s a breadcrumb.

5. Don’t Log What You Shouldn’t Log

This is the other side of the balance: logging too much isn’t just noisy — it’s dangerous.

The most common mistake is inadvertently logging Personally Identifiable Information. These data points must be protected. Logs often lack the access controls, making them an easy weak point for attackers. Never log:

• PII (names, emails, phone numbers)  
• Secrets, tokens, credentials  
• Session IDs  

Anything you don’t have a clear operational need for  

If you don’t know why you’re logging it, don’t.

6. Avoid Duplicate Logs: Log an Event Once, Not Everywhere

One of the easiest ways to drown a system in noise is to log the same event multiple times at different layers of the call stack. It usually happens with good intentions: a controller logs that an operation started, the service logs that it’s handling it, the repository logs that it’s saving something, and then the error handler logs the failure again just to be safe.

The rule is simple:

Log an event, once, at the layer that owns the meaning.

This keeps logs clean, reduces noise, and ensures each log line represents a unique event in the system’s behaviour.

7. Temporary Logging Is a Feature, Not a Failure

One of the most important lessons teams forget:

Just because you add logging to gain confidence during a release doesn’t mean it must live forever.

Temporary logs are fine, even healthy, when:

• You’re validating a new workflow  
• You’re monitoring a new integration  
• You’re rolling out a risky change  
• You’re diagnosing a production issue  

But once the confidence is earned, remove them. If a log line has no long‑term purpose, it becomes noise.

Think of logs like scaffolding: essential during construction, dangerous if left up indefinitely.

8. The Golden Rule: Log With Intent

Every log line should answer one of these questions:

1. Did something meaningful happen?  
2. Did something unexpected happen?  
3. Did something fail?  
4. Will this help us diagnose an issue later?  
5. Will this help us understand a long‑running process?

If it doesn’t satisfy at least one, delete it.

• Logging is not about volume. It’s about clarity.  
• It’s not about reassurance. It’s about evidence.  
• It’s not about narrating the code. It’s about understanding the system.

When developers internalise this, logs stop being noise and start being insight.

Finally

Judicious logging is ultimately an exercise in discipline. Every log line is a decision: does this help us understand the system, diagnose a failure, or operate with confidence, or is it just noise? 

When teams log with intent, they produce a stream of durable, meaningful signals rather than a haze of activity. When they don’t, even the best tools, dashboards, and alerts can’t rescue them from their own verbosity. 

The goal isn’t to log more or less, but to log well. To capture the events that matter, avoid the ones that don’t, and remove temporary scaffolding once confidence is earned. Do that consistently, and your logs stop being a liability and become one of the most powerful tools you have for building reliable, comprehensible systems.