hectoday
DocsCoursesChangelog GitHub
DocsCoursesChangelog GitHub

Access Required

Enter your access code to view courses.

Invalid code

← All courses Logging and Observability with @hectoday/http

Why Logging

  • console.log Is Not Enough
  • What to Log
  • Project Setup

Structured Logging

  • JSON Logs
  • Log Levels
  • Building a Logger

Request Logging

  • Request IDs
  • Request-Response Logging
  • Error Logging

Context and Correlation

  • Log Context
  • Child Loggers
  • Correlating Across Services

What to Observe

  • Business Event Logging
  • Performance Logging
  • Health and Metrics

Production

  • Log Output and Transport
  • Sensitive Data
  • Checklist and Capstone

console.log Is Not Enough

The production debugging problem

Your API handles 1,000 requests per minute. A user reports: “My order failed around 2:30 PM.” You open the server logs:

Server started on port 3000
Received request
Processing order
Error: something went wrong
Received request
Book not found
Received request
Processing order
Order created
Received request
...

Which “Error: something went wrong” is the user’s? There are hundreds of errors. There is no timestamp, no user ID, no request ID, no context. You cannot search for the user’s request. You cannot filter by time. You cannot distinguish one error from another.

This is what happens when console.log is your logging strategy.

What is wrong with console.log

No structure. console.log("Error:", error.message) produces a plain string. You cannot search by field, filter by level, or parse the data programmatically.

No timestamps. When did this happen? console.log does not include a timestamp. In a stream of thousands of log lines, you cannot tell when anything occurred.

No context. Which request caused this error? Which user? Which endpoint? console.log only knows what you explicitly pass to it — and in practice, developers pass the bare minimum.

No levels. Is this a debug trace, an informational message, a warning, or a critical error? console.log treats everything the same. In production, you want to see errors but not debug traces — but they are all mixed together.

No filtering. With 10,000 log lines per hour, finding the one error you care about means reading all of them. There is no way to search for “errors in the orders endpoint between 2:00 and 3:00 PM.”

What structured logging looks like

{
  "timestamp": "2024-01-15T14:32:05.123Z",
  "level": "error",
  "message": "Order creation failed",
  "requestId": "req_a1b2c3",
  "userId": "user-42",
  "method": "POST",
  "path": "/v2/orders",
  "error": "Insufficient stock",
  "duration": 45
}

One line. Machine-parseable JSON. Every field is searchable: filter by level=error, search for userId=user-42, find requests to /v2/orders between 14:30 and 14:35, see the duration.

The user’s failed order? Search for userId=user-42 and level=error around 14:30. Found instantly.

The logging journey

This course replaces console.log with structured logging, step by step:

Section 2: Build a logger that outputs JSON with timestamps and levels.

Section 3: Attach request IDs to every log entry. Log every request and response automatically.

Section 4: Add user context, correlate logs across services.

Section 5: Log business events and performance metrics.

Section 6: Handle production concerns — output, rotation, sensitive data.

Exercises

Exercise 1: Open the logs of any running server. Try to find a specific request from 10 minutes ago. How long does it take?

Exercise 2: Count how many console.log statements are in one of your previous course projects. What context does each one include?

Exercise 3: Write a JSON log entry by hand for: “User user-42 created order order-99 at 2:30 PM, took 45ms.” Include all useful fields.

Why are unstructured console.log statements insufficient for production?

What to Log →

© 2026 hectoday. All rights reserved.