Q242: Error Reporting, Logging and Client Observability

What Interviewers Want To Evaluate

Interviewers want to know whether you can turn client errors into actionable engineering signals.

They check error boundaries, global handlers, unhandled promises, logging levels, sampling, grouping, release context, breadcrumbs, privacy, performance correlation, and alert quality.

Short Interview Answer

Client observability should capture actionable errors with release, route, browser, device, feature flag, and user-action context while avoiding sensitive data. I use error boundaries for render failures, global handlers for uncaught errors and unhandled rejections, typed error categories for expected failures, and sampling or grouping to reduce noise. Alerts should focus on user impact and regression, not every console warning.

Detailed Interview Answer

Client observability answers:

what failed
where it failed
who was affected
which release introduced it
what the user was doing
how often it happens
whether it affects performance

Without context, errors become noise.

Error Sources

Frontend errors can come from:

render failures
event handlers
async requests
unhandled promise rejections
third-party scripts
hydration mismatch
worker errors
storage quota failures
browser compatibility gaps

Each source may need different handling.

Error Boundaries

React error boundaries catch render errors in their subtree.

Use them to protect areas:

reader page
practice console
batch artifact panel
settings page
optional widgets

Do not rely on one global boundary for all UX.

Localized boundaries preserve the rest of the page.

Global Handlers

Global handlers catch uncaught errors.

Examples:

window.onerror
unhandledrejection
worker.onerror

They are useful for visibility.

They are not a replacement for local recovery.

Expected vs Unexpected

Expected failures should be modeled.

type AppError =
  | { kind: "network"; retryable: boolean }
  | { kind: "validation"; fields: Record<string, string> }
  | { kind: "auth"; action: "login" };

Unexpected failures should be reported and recovered through boundaries.

Do not log every expected validation error as an incident.

Breadcrumbs

Breadcrumbs show what happened before an error.

Useful breadcrumbs:

route opened
question id
batch slug
practice run clicked
feature flag state changed
API request failed

Avoid sensitive raw inputs.

Breadcrumbs should explain the path to failure.

Grouping

Error grouping prevents alert storms.

Group by:

error type
stack trace
release
route
component

Poor grouping creates duplicate issues.

Over-grouping hides distinct bugs.

Alerting

Alert on user impact.

Good signals:

new error in latest release
error rate spike
high-impact route affected
checkout or login failures
practice console crash spike
same error with poor INP

Bad signals:

every console warning
known bot noise
single low-impact browser extension error
expected validation failures

Alerts should wake humans only when action is likely.

Privacy

Client logs can leak data.

Never log:

passwords
tokens
private document content
payment details
full sensitive URLs
raw form fields without policy

Scrub or avoid sensitive fields at the collection boundary.

Correlation With Performance

Errors and performance often correlate.

Examples:

third-party script throws and blocks main thread
hydration error causes rerender
API failure creates retry storm
storage quota error breaks offline cache
worker crash moves CPU work to main thread

Include release and route fields across error and performance events.

Common Mistakes

Common mistakes include:

logging too much noise
missing release context
not capturing unhandled promise rejections
logging sensitive data
alerting without ownership
using one global fallback for every error
not connecting errors to user actions

Observability should improve decisions.

Senior Trade-Offs

More telemetry is not always better.

Trade-offs:

context vs privacy
sampling vs completeness
alert sensitivity vs fatigue
local recovery vs implementation complexity

Choose observability based on operational use.

Interview Framing

In an interview, say:

I treat client errors as operational data. I capture release, route, action, browser, and flag context, group and sample intelligently, avoid sensitive data, and alert on user-impacting regressions.

Revision Notes

• Error boundaries catch render errors locally.
• Global handlers catch uncaught failures and unhandled rejections.
• Expected failures should be typed and handled, not always alerted.
• Breadcrumbs explain user path.
• Alerting should focus on impact and regression.
• Privacy rules apply to logs.

Follow-Up Questions

• What does an error boundary catch?
• Why capture release context?
• What should be excluded from client logs?
• How do breadcrumbs help debugging?
• How would you reduce alert noise?

How I Would Answer This In A Real Interview

I would say client observability should make production failures actionable. I would use localized error boundaries, global handlers, release and route context, breadcrumbs, and typed error categories. I would avoid sensitive data, group and sample noise, and alert on new or high-impact regressions rather than every expected failure.