Error monitoring matters more when you're alone

Without it, the only way I'd know something broke in production is a user reporting it — if they bother — and by then there's no stack trace, no request context, no idea how many others silently hit the same error and gave up quietly. Sentry catches unhandled exceptions as they happen, captures the stack trace plus surrounding context — request data, user info if attached, breadcrumbs leading up to it — and surfaces it immediately, often before anyone reports anything.

Sentry.init({ dsn: SENTRY_DSN, environment: process.env.NODE_ENV });

This matters disproportionately for a solo project. With no team independently noticing something's broken through day-to-day use or code review, a solo developer's only real early-warning system is active monitoring or manually checking logs — and manually checking logs doesn't happen consistently. For a team it's valuable but somewhat redundant with human eyes; for a solo maintainer it's the primary net.

A few things that make it usable rather than noisy:

• Sentry groups similar errors — same shape, repeating — into one issue rather than flooding a channel with a thousand near-identical alerts. Without that, high-volume errors get ignored from alert fatigue, or the alerting itself trains you to stop looking.
• Tag every error with the environment. A developer's local error, expected and constant during active development, should not have the same urgency as a real production incident. Without the tag, dev noise and real alerts blur into one stream.

The deploy health check only verifies the app is running and responding to /health. Sentry is what catches "the app is up, but this one flow has been broken for six hours and nobody noticed" — a much more common failure mode in practice than the app being fully down.

Error tracking has its own cost — a small per-request overhead, and a real risk of accidentally capturing sensitive data in an error's context if scrubbing isn't configured deliberately. Worth actively reviewing what ends up in captured payloads rather than trusting the SDK's defaults, especially for a system handling people's personal information.