Skip to main content

Error logging

In short: why log errors at all

Error logging is a way to see what actually happens for users and on the server, instead of guessing from feedback and blank screens.

Without logs you are effectively "blind" - React can show a fallback, but you won't know why everything broke and how many users were affected.


1. To understand what went wrong

Errors can be:

  • in React components (rendering, effects);
  • in asynchronous requests (fetch, axios);
  • in business logic (validation, calculations);
  • in the infrastructure (SSR, API, database).

Without logs:

  • you see "Error", but you don't know where, why, with what data, or on which version of the code.

With logs:

  • you see the call stack, the time, the component, the user agent, the state.

2. For fast debugging and reproducibility

When an error hits the system (for example, via ErrorBoundary or window.onerror), you can:

javascript
componentDidCatch(error, info) { sendToGlitchTip({ message: error.message, stack: error.stack, componentStack: info.componentStack, url: window.location.href, }); }

This lets you:

  • instantly understand exactly where and in which component things broke;
  • filter by release version, browser, platform;
  • reproduce and fix things quickly.

3. For prioritizing bugs

Not all errors are equally important:

  • one shows up for 0.01% of users - it can wait;
  • another shows up for 60% - it needs to be fixed urgently.

Logging systems (Sentry, GlitchTip, LogRocket, Datadog, etc.) group errors, and show frequency, users, device, and release. → This helps set priorities instead of putting out fires at random.


4. For quality control and regressions

After deploying a new version, you see a spike in new errors → a regression. Logging plus release tags (release: v1.5.2) let you:

  • compare "before/after" metrics;
  • roll back a release when there's a spike;
  • monitor the stability of builds.

5. For security and auditing

Logs can record:

  • unauthorized access attempts;
  • invalid tokens;
  • suspicious payloads.

This matters for:

  • incident investigation (security/audit trail),
  • compliance requirements (GDPR, SOC2, PCI).

But: never log personal data (PII) - email, passwords, tokens, card numbers. Use masking (user_id, ***@***.com).


6. For understanding the user experience

Errors are not always bugs in the code. Sometimes they are "unforeseen scenarios": bad data, a poor internet connection, third-party plugins.

With logs you see:

  • in which browsers the UI crashes more often;
  • which regions have network problems;
  • what breaks in mobile Safari versus Chrome.

This helps improve UX and the infrastructure.


7. For learning and documentation

Every error is a signal about a gap in validation, typing, or architecture. If you log and classify errors, then:

  • "lessons learned" can be automated;
  • tests and linters can be improved;
  • documentation can be updated.

Where and how to log in the React ecosystem

PlaceToolExample
UIErrorBoundary + componentDidCatchsendToGlitchTip(error, info)
Clientwindow.onerror, window.onunhandledrejectionglobal JS errors
Async fetchtry/catch + a centralized logError(e)logging network failures
Server (NestJS / Node)LoggerService, Sentry, winston, pinologging the backend
CI/CDGitHub Actions logs, build step logscatch build errors

Example: a minimal client integration (GlitchTip / Sentry)

javascript
import * as Sentry from "@sentry/react"; import { BrowserTracing } from "@sentry/tracing"; Sentry.init({ dsn: import.meta.env.VITE_SENTRY_DSN, integrations: [new BrowserTracing()], tracesSampleRate: 0.1, environment: import.meta.env.MODE, release: "my-app@" + import.meta.env.VITE_APP_VERSION, }); function App() { return ( <Sentry.ErrorBoundary fallback={<h2>Something went wrong</h2>}> <MainRoutes /> </Sentry.ErrorBoundary> ); }

Now:

  • errors from React components, async code, and global JS errors all flow into Sentry/GlitchTip;
  • you can see the stack, the browser, the user (if anonymized).

Summary:

Error logging is not just debugging, it is a single system for observing the health of the application.

What logging gives you:

  1. Understanding the causes of failures
  2. Fast debugging
  3. Prioritization and stability metrics
  4. Security and auditing
  5. Better code quality and UX

Short Answer

Interview ready
Premium

A concise answer to help you respond confidently on this topic during an interview.