What is error tracking? A practical guide for developers
Logs tell you what your application said. Error tracking tells you what actually broke, for whom, how often, and — with the right tool — why. This guide covers how error tracking works end to end, from the SDK in your app to the issue on your screen, and what separates a usable setup from a noisy one.
Error tracking vs logging vs APM
The three overlap but answer different questions. Logging is a chronological record of what your app chose to write down — great for auditing a specific request, terrible for spotting patterns. Error tracking captures unhandled (and handled) exceptions as structured events: stack trace, release, user, browser, breadcrumbs. APM measures performance: transaction latency, database time, throughput.
A mature setup uses all three, but if you have none, start with error tracking: it is the cheapest to add (one SDK, one DSN) and it surfaces the problems your users are actually hitting right now.
How an error becomes an issue
- 1Capture — the SDK hooks your runtime's error paths (
window.onerror, unhandled promise rejections, framework middleware) and serializes the exception with its stack trace and context. - 2Enrichment — the SDK attaches what it knows: release version, environment, user id, OS/browser, and breadcrumbs (the console logs, clicks and network calls that led up to the crash).
- 3Ingestion — the event is POSTed to your tracking backend, where it is scrubbed of sensitive data, rate-limited and stored.
- 4Grouping — the backend fingerprints the event (normally by exception type + normalized stack frames) and folds it into an existing issue or opens a new one.
- 5Alerting — new issues, regressions and spikes trigger notifications so a human looks at the right moment — not at every single event.
What good grouping looks like
Fingerprinting normalizes away the volatile parts of a stack trace — line numbers that shift between releases, hex addresses, request ids — and keeps the stable ones: exception type, function names, in-app frames. Recursion gets collapsed, chained exceptions (caused by) are folded in, and message-only events get their numbers and UUIDs parameterized so Timeout after 30s for user 8123 and Timeout after 30s for user 9411 land in the same issue.
You also want an escape hatch: custom fingerprints for the cases the default heuristics get wrong, and server-side grouping rules so you can fix bad grouping without redeploying your app.
The triage workflow
An error tracker is an inbox, and inboxes need a workflow. The one that works for most teams:
- New issues get looked at daily — most are either real bugs (assign them) or noise (ignore them, ideally with an inbound filter so they stop counting against quota).
- Resolved means fixed in a release — and the tool should reopen the issue automatically if it comes back (a regression).
- Assignment routes an issue to the person who owns that code — ownership rules that map file paths to teams make this automatic.
- Spikes matter more than existence. An error that has fired twice a day for a year is background noise; the same error at 400/minute is an incident.
Context that actually helps you fix the bug
The difference between a five-minute fix and an afternoon of guessing is usually context. Look for: source maps (so minified browser traces show your real code), breadcrumbs (what happened in the 30 seconds before the crash), release tracking (which deploy introduced it, and which commit is suspect), and session replay (a video-like reconstruction of the user's session).
Choosing a tool in 2026
| What to check | Why it matters |
|---|---|
| SDK ecosystem | You want mature SDKs for every platform you ship. The Sentry SDK protocol has become the de-facto standard — tools that speak it (like jentry) inherit the whole ecosystem. |
| Grouping quality | Bad grouping multiplies your alert noise and your bill. |
| Pricing model | Volume-based pricing punishes incidents — the moment you most need the tool. Flat plans keep the bill predictable. |
| Performance monitoring | Errors and latency are two symptoms of the same system; having both in one UI halves your debugging loop. |
| Data ownership | Can you export? Can you delete? Where is it stored? |
If you already use Sentry SDKs, the switching cost between backends is close to zero — the DSN is one config value. That is the approach jentry takes: keep the SDKs, point the DSN at jentry, and get error tracking, APM, replays and release health at a flat price.
Frequently asked questions
Do I need error tracking if I already have logs?
Logs are unstructured and passive — nobody reads them until something is already on fire. Error tracking is active: it groups failures, counts affected users, and alerts you when something new appears. Most teams keep both.
Does the SDK slow my app down?
Modern SDKs are designed to be near-zero overhead in the happy path — capturing only fires on errors, and transport is async and batched. Performance tracing adds sampling controls so you decide the overhead.
Should I capture handled exceptions too?
Yes, selectively. A caught-and-retried network error may be fine at 1/hour and an incident at 500/hour. Capturing it (at warning level) gives you the trend without paging anyone.
What about privacy and PII?
Good tools scrub obvious secrets (passwords, tokens, cookies) server-side by default and let you configure more. Send user IDs rather than emails when you can.
Try jentry free
Hosted error tracking & performance monitoring. Works with your Sentry SDKs — send your first event in minutes.