Why console.log Isn't Enough

Objectives

By the end of this lesson, you should be able to:

• List the specific gaps in console.log for a production application
• Explain what “structured logging” means, and why it matters
• Recognize logging as a distinct concern from error handling

💡 Why this matters: This course has used console.log throughout, for learning, that’s fine, every output shown so far was read immediately, by the same person who ran the code. A real, running application has no one watching the terminal, this lesson covers what that actually requires.

What console.log Actually Gives You

console.log('User logged in:', email);
console.log('Login failed for:', email);
console.error('Database error:', err);

This works while a developer is watching a terminal directly. It stops working the moment an application runs unattended, on a server, for days, handling thousands of requests, with no one reading the output live.

The Specific Gaps

Four gaps, once an application is actually running in production, each one matters:

No levels. console.log and console.error are the only real options, no way to distinguish “routine informational event” from “something is actively broken”, without inventing that distinction by hand every time.

No structure. Each line is free-form text, email might appear as the second argument in one line and be string-concatenated into a sentence in another, nothing about the format is consistent or predictable.

Not searchable. In production, logs are usually collected and searched by tools built for structured data, "level":"error" and "userId":42 as actual queryable fields, a free-text sentence like Login failed for: erin@example.com isn’t something a log aggregation tool can reliably filter or alert on.

No context. A single request often produces several log lines, which request did a given error line belong to? console.log alone has no built-in way to tie related lines together.

What Structured Logging Solves

A structured log line is data first, not a sentence, typically JSON, with consistent fields, a level, a time, a msg, and whatever other fields matter, userId, status, err. This is exactly what the next lesson’s logging library produces automatically, every line the same shape, machine-parseable, filterable by level, and easy to correlate to a specific request.

Logging Is Not Error Handling

Node.js & Express Foundations covered catching errors correctly, try/catch, error-handling middleware, so a bad request doesn’t crash the server. Logging is a separate concern: catching an error stops it from crashing anything, logging it is what makes it visible, to a person, later, who wasn’t watching when it happened. A perfectly caught error that’s never logged anywhere is invisible, no one finds out it happened at all, this module’s later lessons wire both together correctly.

Try It

1. Look back at an error-handling middleware example from earlier in this course, and identify whether the caught error is logged anywhere, or only turned into a response.
2. Write out, in your own words, why “not searchable” is a real problem for an application handling real production traffic, not just a nice-to-have.
3. Sketch, in words, what fields a log line for “a login attempt failed” should probably include beyond just a message, considering what someone debugging a spike in failed logins a week from now would want to know.

Recap

• console.log has no levels, no structure, isn’t searchable, and doesn’t tie related lines to the same request, fine for learning, insufficient for production.
• Structured logging means consistent, parseable log lines, typically JSON, with fields a real logging system can filter and search on.
• Logging and error handling are related but distinct: handling stops a crash, logging makes the failure visible to someone who wasn’t watching.

Next lesson: Pino, a structured logging library, with real log levels and real JSON output.