Production error tracking: exception, grouped issue, next action

Production error tracking means three objects when a real user hits a throw: the SDK sends an exception, the host groups it into one issue with a climbing count, and you open a readable stack to decide the next action (fix, ignore, or resolve). Epure stores that path. It does not store session replay, distributed traces, profiles, or application logs.

What you open in an incident

You open the issue list. The title is the exception type. The count is still moving. The first in-app frame names your file and line. Alerts point at that row. If that is not the screen you want, you are shopping a different product. Longer opinion: You don't need an observability platform. Decision depth: When error tracking is enough.

How grouping works here

Default grouping is SHA-256 of exception type plus the top in-app frame (file, function, line) in crates/envelope/src/fingerprint.rs. Same TypeError from the same line becomes one issue. Same type from another function becomes another issue. A custom SDK fingerprint array overrides the default hash. There is no "similar errors" score. Minified frames without source maps poison the key. Fix maps for the release; do not expect a smarter clusterer.

Prerequisites

Epure up. GET /health returns {"status":"ok"}. Official Sentry SDK for the runtime. CI pins @sentry/browser and @sentry/node at 7.120.0 on this site. DSN from Settings → SDK connection: public key, host, numeric project id. Set tracesSampleRate, replay sample rates, and profilesSampleRate to 0 where the SDK exposes them. Point the DSN. SDK matrix.

Worked verify

import * as Sentry from "@sentry/node"; · Sentry.init({ · dsn: process.env.SENTRY_DSN, · tracesSampleRate: 0, · profilesSampleRate: 0, · }); · Sentry.captureException(new Error("Epure verify test"));

Expect HTTP 202 and { "id": "…" }. Issues shows one unresolved row. Send again: the count rises on the same issue. Verify.

Failures you will hit

401 invalid_dsn or 403 dsn_revoked: Invalid DSN. 202 with an empty Issues list, spike valve soft-drop, or 403 ingest_cap_exceeded: Events not showing. Wrong environment chip hiding the row is the quiet one.

Who this is for

SaaS and B2B production teams, indie developers, and founders who need the stack when production throws. Not a toy-only framing. If you need replay or APM as the daily tool, keep a suite. Error tracking vs APM vs replay.

Limits

Partial Sentry compatibility only. No iOS/Android crash product. Cloud list prices exist; Cloud is not live. Self-host: two containers, PostgreSQL 16, Apache 2.0. Installation.

Releases and the next action

A production issue is not done when you read the stack. You ship a fix under a release string the SDK already sends, mark the issue resolved, and watch whether the fingerprint returns. If it returns on the new release, you have a regression, not a ghost. Epure keeps that issue-centric loop. It does not invent a service map to postpone the patch.

Breadcrumbs the SDK attached before the throw stay useful when they name the last HTTP call or user id. They are not a substitute for logs. If you need a full request timeline across services with no exception, that is APM or logs, and you should buy those jobs explicitly.

SaaS and B2B proof nouns

A B2B team usually cares about: which tenant, which release, which owner. Put tenant id in SDK context if you have it. Put the release in CI. Put the owner in the alert route. None of that requires a suite. It requires discipline on the exception event. Indie solos skip tenant routing; they still need release strings if the UI is minified.

What we refuse to claim

We refuse "complete visibility," "effortless," and "full Sentry replacement." We refuse Cloud list prices CTAs while Cloud is not live. We refuse Redis/Kafka/ClickHouse as defaults. We refuse SQLite as the primary store. The product is two containers and exception ingest. That is enough for many production apps and not enough for every monitoring RFP.

Takeaway

Production error tracking is the issue screen and the next action. If that is your incident habit, two containers and a DSN swap are enough to start. If your habit is replay or traces, keep those products on purpose. Do not inherit them as silent sample rates.