Suggest an editImprove this articleRefine the answer for “Error logging”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**Error logging is a way to see what actually happens for users and on the server**, instead of guessing from feedback and blank screens. **Key point:** without logs a team is effectively "blind" - React can show a fallback, but without logs there is no way to know why something broke and how many users were affected.Shown above the full answer for quick recall.Answer (EN)Image## 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 | Place | Tool | Example | |---|---|---| | **UI** | `ErrorBoundary` + `componentDidCatch` | `sendToGlitchTip(error, info)` | | **Client** | `window.onerror`, `window.onunhandledrejection` | global JS errors | | **Async fetch** | `try/catch` + a centralized `logError(e)` | logging network failures | | **Server (NestJS / Node)** | `LoggerService`, `Sentry`, `winston`, `pino` | logging the backend | | **CI/CD** | GitHub Actions logs, build step logs | catch 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 UXFor the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.