Somewhere in your product there is a bug you don't know about, and a user just hit it. They didn't file a report — users almost never do. They refreshed, muttered, and maybe churned. Error tracking exists so that moment reaches you as a stack trace instead of a mystery, and it's the single highest-value piece of observability a small team can add.
The default answer is Sentry, and Sentry is genuinely good software. But "good" and "right-sized" are different things. As your traffic grows, event-based pricing has a way of turning a noisy release into a surprise invoice, and the feature surface — tracing, profiling, replays, dashboards — grows far past what a two-person team will ever open. If you've felt that mismatch, you're the audience for this post.
What error tracking must do (the non-negotiables)
- Capture everything, automatically. Unhandled exceptions, from every environment, with stack traces, request context, and the release they belong to. If capturing requires remembering to wrap code, it will miss the bug that matters.
- Group intelligently. Ten thousand occurrences of one bug are one problem, not ten thousand. Deduplication is the difference between a signal and a siren.
- Tell you once, in the right place. A new error should reach Slack or email the first time it happens — then stay quiet while the counter climbs.
- Show the trend. Is this error new in this release? Regressed after being fixed? Spiking? That's triage, and it should take one glance.
Notice what's not on the list: distributed tracing across forty microservices, session replay, profiling flame graphs. Those are real features for the companies that need them — and dead weight for a Django monolith with a React frontend and four engineers.
Where the Sentry bill actually comes from
Sentry charges by event volume, and error volume is the least predictable number in your system. A dependency update that breaks one endpoint can emit six figures of events overnight — precisely when you're too busy firefighting to tune sampling. Teams respond by dropping events, which quietly undermines the whole point, or by upgrading plans mid-incident. The team at Jentry wrote up this dynamic (with numbers) in "Sentry is too expensive", and it matches what most small teams eventually feel: you're paying for capacity you only need on your worst day.
The case for a lighter alternative
Jentry is error tracking built deliberately at the small-team size: the capture-group-alert-trend loop done well, flat predictable pricing instead of per-event anxiety, and a setup that takes minutes because it's SDK-compatible with what you already have. If your code is instrumented for Sentry today, the migration guide is mostly "change the DSN" — which also makes it a low-risk experiment: run both for a week and see which one you actually read.
When you're evaluating any alternative — Jentry or otherwise — the comparison that matters is not feature-count. It's:
- Time-to-first-insight: from signup to "I can see my real errors" should be under fifteen minutes.
- Cost at your p95 month, not your average month. Model the bad release, not the calm one. (Jentry's pricing is flat for exactly this reason.)
- Signal quality: subscribe both to Slack for a week; the right tool is the one whose notifications you didn't mute.
When you genuinely need the heavyweight
Honesty cuts both ways. If you run many services and regularly debug cross-service latency, if compliance requires session-level forensics, or if a platform team owns observability full-time — the Sentry/Datadog tier is built for you, and a lightweight tracker will feel thin. The mistake isn't choosing the big tool; it's defaulting to it years before your problems reach that shape, and paying the complexity tax the whole way. A broader survey of the field, including the open-source self-hosted options, is in Jentry's Best Sentry Alternatives in 2026.
Errors are inevitable; not knowing about them is optional. Pick the tool sized to your team, wire the Slack alert, and the next production bug will introduce itself before your users have to.