Error tracking
A service that catches every exception your live app throws, groups the duplicates, and tells you which ones are hitting real users.
See it
What it is
Error tracking is a service that catches every exception your running app throws, packages it with a stack trace, breadcrumbs, release, and user context, then collapses the duplicates into one issue you can actually triage. Sentry, Bugsnag, Rollbar, and Honeybadger are the usual names. The value is not the capture, it is the grouping: 40,000 crashes become one issue that says 'started three hours ago, release abc123, 812 users affected'.
Install it before your first real user, on both server and browser. The setup that pays for itself: tag every event with the release SHA so a spike points at a deploy, attach a user id (an id, not an email) so you can tell one loud bot from a broken checkout, and alert only on new or regressed issues rather than on every event.
Gotcha: without uploading source maps at build time, every frontend stack trace is minified gibberish pointing at line 1 of main.js. The other reason teams stop looking at the inbox is browser noise: extension errors, ResizeObserver loop warnings, and cancelled network requests from users closing tabs. Filter those aggressively on day one, because an ignored error inbox is worse than none.
Ask AI for it
Wire Sentry into this app for both client and server. Initialize with the DSN from the environment, set environment and release to the git SHA, and upload source maps during the production build so traces are readable. Capture unhandled exceptions and unhandled promise rejections, attach the authenticated user id (never the email) and the current route as tags, and add breadcrumbs for navigation and API calls. Set a 10 percent traces sample rate, ignore ResizeObserver loop errors, browser extension frames, and aborted fetches, and add a throwaway route that throws on purpose so I can verify the pipeline.