How to Set Up Error Tracking for Production Apps

Error tracking vs. logging

Logging records a stream of events. Error tracking is purpose-built for one thing: capturing exceptions, grouping them intelligently, and telling you which ones matter. The difference is signal. A log search shows you 50,000 lines; an error tracker shows you "this TypeError happened 4,213 times across 312 users, first seen 2 hours ago, here's the stack trace and the request that caused it."

If you only have logs in production, you're flying blind on errors.

What good error tracking captures

For every exception, you want:

• The full stack trace, deminified if it's frontend code.
• Context: which user, which request, which release, which environment.
• Breadcrumbs: the events leading up to the error.
• Grouping: identical errors collapsed into one issue with a count.
• Frequency and trend: is this new, spiking, or background noise?

Capturing errors in the backend

Most error trackers (Sentry, GlitchTip, Rollbar, Bugsnag) provide an SDK. The pattern is: initialize early, capture unhandled exceptions automatically, and add context.

// Node example (Sentry-style API; GlitchTip is API-compatible and open source)
const Sentry = require('@sentry/node');
Sentry.init({
  dsn: process.env.ERROR_DSN,
  environment: process.env.NODE_ENV,
  release: process.env.GIT_SHA,        // tie errors to a deploy
  tracesSampleRate: 0.1,
});

// Express: capture handler errors automatically
app.use(Sentry.Handlers.errorHandler());

// Manual capture with context
try {
  await chargeCard(order);
} catch (err) {
  Sentry.captureException(err, { extra: { orderId: order.id } });
  throw err;
}

The release field is underrated: tagging every error with the deploy SHA lets you instantly see "errors spiked right after release abc123" and roll back with confidence.

Capturing errors in the frontend (and source maps)

Frontend errors come minified, a is not a function at t.x (main.abc.js:1:99999). Useless. The fix is source maps: upload them at build time so the tracker can map the minified stack back to your real source.

# During CI build, upload source maps then strip them from the public bundle
sentry-cli sourcemaps upload --release "$GIT_SHA" ./dist

Upload source maps privately to the error tracker; don't serve them publicly. This single step is the difference between actionable frontend errors and noise.

Grouping and fingerprinting

A good tracker groups errors by a fingerprint (usually the error type + top stack frames) so a million occurrences of the same bug are one issue. Sometimes the default grouping is wrong, too coarse (unrelated errors merged) or too fine (one bug split into many). Most trackers let you set a custom fingerprint to fix this. Tune it when an issue's grouping is hiding the real shape of a problem.

Adding the context that saves you

The stack trace tells you *where*; context tells you *who and why*. Attach:

• User identity (id, not PII you don't need).
• Request data: URL, method, sanitized params, correlation ID.
• Custom tags: feature flags, tenant/org ID, plan tier.

Sentry.setUser({ id: user.id });
Sentry.setTag('org_id', org.id);
Sentry.setContext('request', { url: req.url, request_id: req.id });

The correlation ID is the bridge between your error tracker and your logs, find an error, grab its request ID, pull the full log trail.

Avoiding alert fatigue

The fastest way to make error tracking useless is to alert on everything. People mute the channel, and then you miss the real fire. Tactics:

• Alert on new and regressed issues, not every occurrence.
• Set thresholds: page when an issue affects >N users or exceeds a rate, not on the first hit.
• Ignore known noise: bot traffic, browser-extension errors, cancelled requests.
• Route by severity: new payment errors page someone; a cosmetic frontend warning files a ticket.

Wiring it onto your deployment

Error tracking needs two things from your platform: a place to set the DSN/secret as an environment variable, and a way to know the current release. On PandaStack you set the error tracker's DSN as an environment variable on your service, and you can pass the deploy's commit SHA as release so errors map to deploys. Because PandaStack keeps deploy history and supports rollbacks, the workflow becomes: error tracker flags a spike on the latest release → you roll back from the dashboard → the spike stops.

# Set as env vars on your PandaStack service
ERROR_DSN=...        # your tracker's DSN
GIT_SHA=...          # commit of the current deploy, used as `release`

This complements rather than replaces PandaStack's built-in live logs and server-side metrics: metrics tell you error *rates* are up, the error tracker tells you the *exact exception and stack trace*, and logs (with the shared correlation ID) tell you the surrounding story.

A rollout checklist

• [ ] Backend SDK initialized with environment and release.
• [ ] Unhandled exceptions captured automatically.
• [ ] Frontend source maps uploaded in CI, not served publicly.
• [ ] User/request/correlation-ID context attached.
• [ ] Alerts on new/regressed issues only, with sane thresholds.
• [ ] Known noise filtered out.

Conclusion

Error tracking turns "something's wrong" into "this exact bug, this often, since this deploy." The high-leverage pieces are tying errors to releases, uploading source maps, attaching context with a shared correlation ID, and alerting only on what's new or spiking. Set it up before launch, the first production incident is the worst time to discover you have no visibility.

PandaStack gives you the deploy history, rollbacks, env vars, and live logs that make an error tracker actually actionable. Try the workflow on the free tier at https://dashboard.pandastack.io.

References

• Sentry documentation: https://docs.sentry.io/
• GlitchTip (open-source, Sentry-compatible): https://glitchtip.com/documentation
• Source maps spec (MDN): https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map
• Google SRE workbook, alerting on SLOs: https://sre.google/workbook/alerting-on-slos/