Skip to main content
Signals arrive constantly. Most of them are uninteresting, and that is the point: the judgement worth paying for is which few of them matter, and it is worth nothing unless all of them are kept. An investigation is what that judgement produces. It is opened by the product, not by you, and this page is what decides when.

​
The rule, in one sentence

An error your organisation has never stored before opens an investigation, the first time it is seen. That is the whole of the rule. It once had a second half — an error whose rate suddenly stepped up — and that half has been decided against rather than postponed. What it does not do says why. Three things the rule deliberately does not require:
  • No threshold. One occurrence is enough. Waiting for a second puts a floor under how fast anything can be noticed, and the first occurrence is the one worth catching.
  • No release. An investigation opens whether or not we can name the build the error followed. A team whose release strings do not resemble their commits still gets investigations — the finding is weaker, not absent.
  • No configuration. There is nothing to tune, because there is nothing that a wrong setting could switch off.
Errors are grouped the way your source already groups them. For a Sentry source that is the issue, so a thousand occurrences of one error are one thing, seen once.

​
Every evaluation is recorded, including the ones that decided nothing

For each signal, the product records what it decided and why: A quiet week is therefore not an unexplained week. “We looked, and it was nothing” is a claim with a record behind it, and it is the claim that makes silence believable. Without the declines, the product could only ever show what it did and never what it chose not to do.

​
A finding cannot arrive sooner than the next scheduled run

The rule is not evaluated as each signal lands. It runs on a schedule, and that interval is the floor under how quickly anything can reach you. The schedule runs about every five minutes. Treat that as an expectation rather than a guarantee: scheduled runs are best-effort and drift when the world is busy, so a run can be a few minutes late. Everything else the product says about telling you something unasked is true within that bound and not faster. If you need to know within seconds, this is not the thing that will tell you — your error tracker’s own alerting is.

​
One problem, one investigation — even when it arrives twice

Sentry can deliver the same problem down two routes at once: once per issue and once per event. If you configure both against the same project, we store both deliveries, and open one investigation. Both records stay readable on your timeline afterwards. Nothing is dropped at the door and nothing is overwritten — a delivery we refused to store is evidence we edited by omission, and the verbatim body is exactly what lets a wrong reading be corrected later. The de-duplication happens when the rule counts, not when the signal is written.

​
What it does not do

It pages nobody, and it opens no incident. An investigation is a statement that something is worth looking at. Waking a person is a separate decision, made by a person, and nothing on this path can make it — an escalation raised by automation is refused. It does not notice that something already known got worse, and it is not going to. A rate step-up — the same error suddenly firing far more often — was once half of this rule. It is no longer part of it, and that is settled rather than pending: there is no plan, no waiting list and nothing you could configure at your end to switch it on. Two things settled it, and they point the same way.
  • The route we recommend cannot count. The delivery route we ask for when you connect a source is throttled per issue by Sentry, so the count we hold is lower than your true event count by a factor neither of us controls. A number wrong in an uncontrolled direction is worse than no number.
  • Where a rate can be counted, it is already yours. Your error tracker computes it for you, on the issue page, with the stack trace beside it. Re-deriving it worse from the outside would spend your attention and ours on the one thing we would certainly lose at.
So the split is: firsts are ours, rates are yours. Every finding this product opens says an error is new and, where it can, which release it followed. None of them will ever say how often it is firing. That sentence is also on the Sources screen and in the message the team connecting a source sends you, so nobody meets it for the first time after connecting.

​
What you should expect to see

In the first days after a source connects, more investigations rather than fewer: those are the days in which the most things are genuinely new. It settles as your errors stop being new to us. If it never settles — if substantially every error you store opens an investigation — that is worth telling us. It would mean never-before-seen is true of everything for your team, and the rule is discriminating nothing.