> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scaling.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# How an investigation opens

> A never-before-seen error opens an investigation on its own, at the first occurrence, and every evaluation is recorded — including the ones that opened nothing.

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](#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:

| It decided                  | Because                                                         |
| --------------------------- | --------------------------------------------------------------- |
| **Opened an investigation** | This error has never been stored for your organisation before   |
| **Opened nothing**          | This error has been seen before, and is already under one       |
| **Opened nothing**          | The signal is not an error — a deploy, for instance, is context |

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](/guides/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.