Error tracking without tracing or replay: when errors are enough

A customer writes that checkout failed. If your error tracker shows a TypeError in checkout.ts from the release you shipped an hour ago, errors were enough: you have the line, the release and the clicks before it. If it shows nothing because checkout took eight seconds and then succeeded, no amount of error tracking will explain it. This page helps you sort your own incidents into those two kinds, prices the extras, and says when you need them.

When is error tracking enough without tracing or replay?

Error tracking is enough when the failures you care about throw. An error event carries the exception type and message, the stack trace, the release, the environment and the breadcrumbs the SDK recorded before the throw, such as clicks and outgoing requests. For JavaScript, a source map uploaded for the same release turns a minified frame back into your file and line. That covers a 500 from an API route, an unhandled promise rejection, a render error after a deploy and a failed third-party call that raises.

Check it against your own history. Take your last five incidents and write down, for each, the symptom and the signal that explained it. If every row says "stack trace" or "the deploy before it", tracing and replay sat idle for you. A row that says "it was slow" or "the user couldn't click" is the case for keeping a second signal, and only for that row.

What does tracing add that error tracking does not?

Tracing records how long each part of a request took, with the route handler and each database query or outgoing call as a span. Tracing answers "where did the time go" when nothing failed. Sentry samples traces with tracesSampleRate, and its Next.js manual setup starts at 0.1 in production (checked 6 Nov 2026). A Django developer asking why a Celery task got slow was pointed to Sentry's performance tooling in an r/django thread in Sep 2026. That is the job tracing does well.

A trace also links services. With a separate frontend and backend, one trace follows a click through both, and an error carries the trace it happened in. A single Next.js app with one database gets less from this than a team running five services. Less is not nothing: a slow query shows up as a long span before users complain.

What does session replay add, and what does it record?

Session replay records what the user saw and did in the browser, so you can watch the session around a problem. Replay answers UI bugs that never throw: a button behind an overlay, a form that clears itself. Sentry's Next.js replay guide recommends replaysOnErrorSampleRate: 1.0 and a session rate from 0.01 to 0.25 depending on traffic (checked 6 Nov 2026). Replay carries a privacy cost the other signals don't, because it captures what your users see; plan its masking settings and name it in your privacy policy.

What does profiling add?

Profiling samples the call stack while code runs, so it shows which functions burn CPU. Profiling answers "this endpoint is slow and the trace says the time is inside our own code". Sentry sells continuous profiling for servers and UI profiling for browsers, on pay-as-you-go only: $0.0315 per continuous profile hour and $0.25 per UI profile hour (Sentry pricing docs, checked 6 Nov 2026). In our view, a one- or two-developer app reaches for profiling only after tracing has pointed at a function.

What do tracing, replay and profiling cost on Sentry?

On Sentry's Team plan, $29/month on monthly billing, tracing is usually free at small volume and replay and profiling are the first paid lines. The plan includes 50,000 errors, 5,000,000 spans, 50 replays and 5 GB of logs, and no profile hours (Sentry pricing, checked 6 Nov 2026). Past the allowance, every category draws on one pay-as-you-go budget, which Sentry's pricing docs describe as shared first come, first served. A replay spike can spend the budget your errors needed.

The honest reading: for one or two developers on Sentry Team, tracing at Sentry's default production rate rarely costs money. What tracing and replay cost you is attention, with settings spread across runtimes and a recorder in every visitor's browser. Turn them off when you don't read them, not because they are expensive. The Sentry pricing calculator runs the same rates on your own volume.

Do I need APM or just error tracking?

APM, application performance monitoring, is tracing plus the dashboards around it: latency percentiles, throughput and slow database queries. A one- or two-developer SaaS needs APM when users report slowness and error tracking shows nothing, or when requests cross services you can't time by hand. Until then, error tracking plus a few logged timings covers the ground. The deciding test is the table at the top: count how many of your last five incidents sit in the "checkout takes 8 s" row.

A Laravel developer asking which endpoint and query were heaviest was pointed to APM tools and Debugbar in an r/laravel thread in Sep 2026. An error tracker has no answer for that question, and pretending otherwise would waste your afternoon.

When do you need tracing, replay or profiling after all?

You need tracing when slowness is a recurring complaint, when one request crosses 2 or more services you own, or when a database query regresses without throwing. Replay pays off when support closes tickets by watching what the user did, or when UI bugs without exceptions reach customers every month. Profiling is for the moment a trace points inside your own code and you can't see which function. In each case Sentry, or another tool with tracing, is the better choice for that job, and keeping it is a sound decision.

Two gaps sit outside all of these. A job that silently stops never throws, so it needs a cron check-in, and a site that is down for everyone needs an uptime check from outside your servers. Epure includes cron monitors; it does not do uptime.

What does Epure error tracking do without tracing or replay?

Epure error tracking keeps your Sentry SDK and stores errors only: transactions, replays and profiles are dropped on ingest. Each problem is grouped into one issue, alerts fire on a new issue, a regression or a velocity spike, and a looping error is stored at 100 events per minute while every occurrence is still counted. Cloud Pro is $29/month for 200,000 events with no automatic overage (pricing). Epure does not do tracing, replay, profiling, logs, uptime, mobile symbolication or SSO.

Your coding agent can read an issue brief through MCP or the CLI (connect Claude Code or Cursor). Staying on Sentry gets you the same scope if you switch the other signals off: turn off Sentry performance, replay and profiling but keep errors gives the settings per SDK. Epure vs Sentry compares the two on errors alone, with dated prices.

How do you test whether errors alone are enough for your app?

Run errors only for 14 days and keep a list. Turn off tracing and replay in staging first, then in production, using the per-SDK settings. Each time something goes wrong, note whether the error event explained it. If every incident in those 14 days was explained by a stack trace and a release, errors are enough. If one was a slowness or UI case, put that one signal back on purpose; turning tracing on again is one line per runtime.

Epure's trial runs 14 days on Pro limits with no card, so the same window can test both questions: whether errors are enough, and whether a quieter inbox suits you. For the wider picture of a solo founder's setup, read error tracking for a SaaS run by one or two developers.