Error tracking vs APM vs session replay

Error tracking, APM (traces), and session replay answer different questions. Mixing them into one "monitoring" buy is how bills and compose files grow without a job change.

One-line answers

Error tracking answers: what threw, how often, which frame. APM answers: where time went on a request that may not have thrown. Session replay answers: what the user clicked in the UI before something felt wrong.

Matrix

When the 500 is enough

If checkout returns 500 and the stack names chargeCard, you do not need a waterfall to start the patch. You may still want traces later for latency without errors. Opinion depth: No observability platform. When error tracking is enough.

How to stop shipping unused signals

Pointing a Sentry SDK at Epure does not store traces, replays, or profiles. Set rates to 0 so the client stops working for free:

• Tracing: Disable Sentry tracing
• Replay: Disable Sentry session replay
• Profiling: Disable Sentry profiling

Envelope behavior: Envelope keep/drop.

Lived wrong default

We left replaysOnErrorSampleRate: 1.0 on because it felt responsible. Support never watched a replay. The browser still recorded. On Sentry Cloud that is budget. On Epure it is discarded work. Zeroing the rate was the fix, not a new product.

Pick

Buy error tracking when the daily screen is Issues. Buy APM when slow hops without throws are the weekly page. Buy replay when support closes tickets from recordings. Buy a suite when those jobs share one vendor on purpose and you accept the meter or the RAM floor.

Ordered debug for "we thought we needed all three"

• Did anything throw? Open Issues first.
• If yes, read the stack. Patch or fingerprint. Do not open replay yet.
• If nothing threw and users report slowness, now you have an APM question.
• If support cannot reproduce a UI-only glitch with no server exception, now you have a replay question.

Most weeks stop at step 2 for product engineering teams. Suites sell steps 3-4 as default. Defaults have invoices and RAM floors.

Envelope honesty

A mixed envelope can return HTTP 202 while Epure keeps the event item and discards the rest. That success code is not proof that traces were stored. Read Envelope. Set sample rates to 0 to align client work with server scope.

Variety vs observability essays

The redirected /error-tracking-vs-observability topic pointed at No observability platform. This page stays as the three-signal matrix. Do not paste the cafe incident from the essay here. Keep the matrix and the disable-* mesh as the shape.

Takeaway

Pick the signal that matches the question. Exceptions first for throws. Traces for slow hops without throws. Replay for UI-only mysteries. Epure is the exceptions row. Disable the other sample rates when the other end will not store them.

Bias and limits

First-party page. Epure wins the exceptions cell. We still tell you to keep Sentry or another suite when replay or traces are daily work. Cloud list prices are not live checkout. Never claim full Sentry parity.

Procurement language you can paste

"We need grouped exceptions and readable stacks in production. We do not need session replay or distributed tracing in v1. Sample rates for traces, replay, and profiles will be 0. Host may be self-hosted Epure (Apache 2.0, two containers, PostgreSQL 16) with a Sentry SDK DSN swap for exception events only (partial compatibility)."

Paste that into the RFC. It prevents a silent suite buy.

Takeaway expanded

Match signal to question. Exceptions first for throws. Disable unused Sentry sample rates when the store will not keep those items. Keep suites when those jobs are daily and funded.

Example week

Monday: 500 on checkout → Issues → patch. Tuesday: p95 latency creep with no throws → APM question for whoever owns performance. Wednesday: support cannot reproduce a CSS overlay bug → replay or a screen recording outside Epure. One product rarely owns all three weeks equally. Stop buying as if it must.