Lesson 23 of 30

Logging, Monitoring & Observability

Q: A user reports a bug you can't reproduce locally. How would you investigate it using production observability tooling?

A strong answer covers: Distinguish logging (discrete events), monitoring (aggregate metrics/alerting), and observability (can you answer a new question from existing data); Frontend error tracking (e.g. Sentry) automatically captures unhandled exceptions from real users, with source maps for readable stack traces; Structured logs with real context (user id, relevant ids, error detail) are what make a specific report actually investigable.

Once code is running in front of real users, `console.log` and a debugger stop being enough — observability is being able to answer 'what actually happened' after the fact, for a user you can't reproduce the bug in front of.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A production error is logged simply as "Error occurred". Why is this close to useless for actually fixing the bug?

It has no context — no ids, no error detail — leaving nothing actionable to investigateIt's technically impossible for a log statement to run in productionLogging in production is against best practice and should never be done

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Logging, Monitoring & Observability

What interviewers actually ask about this, and what a strong answer has to cover.

A user reports a bug you can't reproduce locally. How would you investigate it using production observability tooling?

A strong answer covers

Distinguish logging (discrete events), monitoring (aggregate metrics/alerting), and observability (can you answer a new question from existing data)
Frontend error tracking (e.g. Sentry) automatically captures unhandled exceptions from real users, with source maps for readable stack traces
Structured logs with real context (user id, relevant ids, error detail) are what make a specific report actually investigable

Likely follow-ups

What's the difference between what monitoring tells you and what logging tells you?
Why do source maps matter for a minified production bundle's error traces?
How would you decide what context to include in an error log without logging sensitive user data?

Practice these with the AI interviewer →

The plain-language idea

Logging records discrete events as they happen ("user 42 clicked checkout," "API call to /orders failed with 500"). Monitoring watches aggregate metrics over time (error rate, page load time, requests per second) and can alert when something crosses a threshold. Observability is the broader property: can you answer a new, previously-unasked question about your system's behavior using the data you already collected, without shipping a new debug build?

try {
  await submitOrder(order);
} catch (err) {
  logger.error("order_submit_failed", {
    userId: user.id,
    orderId: order.id,
    error: err.message,
    // enough context to actually investigate, not just "something broke"
  });
  throw err;
}

Logs, metrics, traces: three different questionsStep 1 of 3

Logs: discrete events — "user 42 checked out at 10:03am." Good for "what exactly happened here."

What people usually miss

Watch out

A log line with no context is close to useless in production. "Error occurred" tells you nothing actionable; a log with the user id, the relevant ids, and the actual error message is what turns an alert into something you can actually investigate and fix.
Source maps matter for frontend error tracking specifically. Production JavaScript is minified — an error's stack trace is unreadable without the matching source map to translate it back to your real source code and line numbers.
Monitoring and logging answer different questions. A monitoring dashboard tells you error rate spiked at 3pm (the "what" and "when"); logs are what let you dig into why, for a specific failing request — you generally need both, not one instead of the other.

Why this matters in interviews

"A user reports a bug you can't reproduce — how do you investigate it?" is a real, practical scenario, and the honest answer routes through observability tooling (error tracking with context, structured logs) rather than "ask them to describe it more."