One bug, one issue, one count you can trust.
Grouping is the whole job of an error tracker, and the count it produces is what tells you which of four hundred problems to fix on a Tuesday morning. Bugtail groups on the shape of the failure, keeps the trace out of the database, and never loses the count when the trace is swept.
Grouped on what makes it the same bug
An exception is fingerprinted on its type and the frames of your own code that produced it, not on the message. That matters because a message usually carries an identifier: "User 8812 not found" and "User 913 not found" are one bug, and an error tracker that shows them as two has turned one problem into a list.
When the grouping is wrong for your application, you can say so per collector. What you cannot do is make it depend on the payload, because the payload is not always there.
The trace never goes in the database
The issues and events tables hold titles, levels, counts, timestamps and a pointer. The trace itself, the request context and the breadcrumbs are gzipped JSON in your bucket. That is not an optimisation, it is the constraint the whole design rests on: it keeps the database small enough to stay fast, it makes retention two separate decisions, and it makes deleting the sensitive part a delete rather than a schema change.
An event row therefore has to stay useful after its payload is gone, and it does: the title, the level, the release, the URL without its query string and the count are all still there a year later, long after the trace has been swept.
Two retention windows
How long an event row lives and how long its payload lives, set separately, per collector.
Counts outlive payloads
Graphs come from rollups rather than from counting rows, so pruning never changes history.
Scrubbed before it is written
Passwords, tokens, cookies, card numbers and IBANs, at any depth, on the way in.
Regressions are a state, not a new issue
Resolve an issue and it closes. If the same fingerprint arrives again, the issue reopens as a regression and says which release brought it back, rather than appearing as something new for somebody to triage from scratch. You can also snooze one until the next release, which is what you actually want for a bug you have already fixed but not yet shipped.
Questions people actually ask
Can I change how errors are grouped?
Per collector, yes. The default fingerprint uses the exception type and your own frames; you can narrow or widen it when your application needs something else.
What happens to an issue when its traces are swept?
It stays. The title, level, release, counts and graphs are all in the database and none of them come from the payload. Opening an old issue shows everything except the trace itself, which says plainly that it has been pruned.
Do you charge for events you group together?
Every event that is recorded counts once, grouped or not. Events refused by your browser allowlist are not counted against you, and neither are events dropped by sampling.
Fourteen days of Team, without a card.
Sign up with your work address, prove your domain with one DNS record, and paste a DSN. The first stack trace usually arrives before the coffee does.
No card. The trial ends by itself and drops to Free; nothing is charged unless you choose a plan.
