> ## 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.
# Signal sources
> The inputs an AI investigation reads — past incidents, GitHub code changes, and Sentry errors — and the finding each one produces.
A **signal source** is an input an [AI investigation](/concepts/ai-investigations) reads when it runs. Each source produces a different **kind** of finding. Sources are additive: every investigation starts with your own incident history, and each integration you connect gives later runs more to work with.
A signal source is read **by** an investigation — it is the opposite direction from an inbound [alert integration](/integrations/inbound-webhooks), which pushes alerts **into** scaling.cloud. Connecting Sentry as a signal source, for example, lets investigations read your Sentry issues; it does not turn Sentry alerts into incidents.
## Finding kinds
| Kind | Source | What it tells you |
| -------------------- | -------------- | --------------------------------------------------------------------------------- |
| `similar_incident` | Past incidents | *"We've seen this before — incident #214, resolved by rolling back X."* |
| `suspect_change` | GitHub | *"Deploy `abc123`, 8 min before the first alert, touched `payments/`."* |
| `root_cause` | Sentry | *"This stack trace points at a null check in `checkout.ts`."* |
| `commit_correlation` | Sentry | *"Sentry flags suspect commit `abc123`"* — corroborating a GitHub suspect change. |
## Past incidents
The built-in source, available to every entitled organization with **no integration to set up**. scaling.cloud matches the open incident against your resolved incidents by symptom and surfaces the closest matches as `similar_incident` findings, with a link to each prior incident and how it was resolved.
This source only ever reads your **own** organization's incidents.
## GitHub — code changes
"What changed recently?" is the most common real root cause. Connecting the GitHub App lets investigations correlate your deploys, merges, and commits to the incident timeline and surface the likely culprit as a `suspect_change` finding.
Changes are matched to an incident by **time and component** — a change to a repository that maps to one of the incident's [affected components](/concepts/components), landing shortly before the incident opened, is a suspect. Monorepos map to different components by path, so a change is attributed to the component it actually touched.
Install the GitHub App and start correlating changes to incidents.
## Sentry — errors and releases
Sentry has already done the hard part of telemetry — grouping errors, capturing stack traces, and linking errors to the release and commit that introduced them. Connecting Sentry lets an investigation read that work and produce two finding kinds:
* `root_cause` — derived from a grouped error's stack trace.
* `commit_correlation` — from a Sentry release's linked commits, corroborating a GitHub `suspect_change` at commit precision.
Authorize scaling.cloud to read your Sentry issues, releases, and stack traces.
## Graceful degradation
Signal sources are independent. If a source is not connected, or a connected source can't be reached during a run, the investigation simply skips it and reports what the other sources found — a missing source never blocks an investigation or holds up paging.
Connecting more sources sharpens findings but is never required. An
investigation always runs against at least your incident history.