It says why, and it says how sure it is

A change is evidence, not history

Almost every platform keeps deployments on a page of their own, as a record of what happened. That is the wrong place for them. The deployment nearest an error’s first sighting is the strongest single piece of evidence about that error, and it belongs on the error.

So that is where it is. An issue carries the deployment closest to when it was first seen, the gap between the two, and — the part that matters — which side of the first sighting the deployment falls on. A release that went out four minutes before the first error is a completely different fact from one that went out four minutes after, and a platform showing you only "recent deploys" has thrown that distinction away.

It is not called a suspect commit, and the refusal is deliberate. The platform knows a change went out near a failure. It does not know the change caused the failure, and calling it a suspect asserts a conclusion from a coincidence. The page says what it knows, and says that a correlation is not a cause.

Graded, not scored

A finding comes back as High, Medium or Low confidence, and the grade is tied to the evidence that produced it: a change inside the window, a configuration edit, independent signals that agree with one another.

The alternative — "98% confident" — is the industry norm and it is a fabrication. There is no calculation behind a number like that, and its practical function is to stop you asking what the evidence was. A grade you can trace to three facts is worth more than a decimal you cannot trace to anything.

Ask it about your own system

Two questions can be put directly to the service map rather than to a chat box that has to guess what your services are. Why did this fail, and what does this thing actually talk to — both answered against your real topology, built from the spans you have already sent.

The answers are model output and are presented as model output. That is not a hedge. It is the difference between a tool you can use during an incident and one you have to audit during an incident.

Review a change before it ships

The same engine reads a diff. A build step posts the change, findings come back as annotations on the pull request, and where a finding justifies a specific edit the edit rides along with it — as a find-and-replace pair checked against the diff that was actually sent.

Nothing is committed and nothing is pushed. SnagSpy holds no credential for your repository, so the edit returns to your pipeline and your pipeline decides whether to apply it. The job needs only permission to read the repository contents, which is a much smaller thing to grant than write access to your default branch.

npx snagspy review --base origin/main

# and, in a developer’s own checkout, to apply what came back
npx snagspy review --base origin/main --fix

Two consents, both off until you turn them on

Telemetry and source code are different categories of secret, and one consent covering both would be a consent nobody could reason about.

AI investigation of your telemetry is one switch, per project. Sending source code for review is a second, separate switch that starts off, with a scope of its own that an API key must carry explicitly. A key that can read your errors cannot send your code anywhere.

What it will not do

The most useful paragraph on this page, and the one most pages like it leave out.

• It does not predict failures. Predicting an outage that has not happened requires guessing, and a guess wearing a confidence grade is worse than silence.
• It does not open pull requests for you, or hold any credential that would let it.
• It is not always right. A finding is model output — evidence-graded, traceable and reviewable, and still something a person has to read.
• It is not billed per contributor. Investigations are metered against your plan.