Skip to main content
NewFeature spotlight

Know why your site changed, not just what.

OnChange correlates every detected change with your recent commits and hands the evidence to Claude. The alert you get names the likely cause, the suspected commit, and a confidence score - so debugging production regressions takes seconds, not hours.

The problem

Detection is the easy part. Attribution is the part that saves your shift.

Every alert asks "who did this?"

A change-detection tool tells you a price went from $99 to $89, or the nav lost a link. The next question is always "why?" - which deploy, which commit, which vendor update. Most tools stop at detection.

Forensics shouldn't take an hour

Without attribution, a production regression means grepping git log, checking the GitHub Actions timeline, opening Sentry, and asking your team who shipped last. By the time you identify the cause, the outage has dragged on.

Not every change is your fault

Third-party scripts, CMS publishes, and CDN edge config rewrites all show up as "the site changed" in naive monitoring tools. Attribution tells you when the cause is outside your team's repo.

How it works

From detection to suspected commit in 3 seconds.

01

Monitor detects a change

OnChange polls your monitored page. When the text, visual, or API diff crosses your threshold, a Change record is created - same as today.

02

Attribution task runs

A background worker pulls recent commits from your configured GitHub repo in the 15-minute window before the change was detected. Commits beyond the window or outside the repo are filtered out automatically.

03

Claude generates a verdict

We pass the diff plus commit list to Claude and ask: does any commit plausibly explain this change? The model returns a one-sentence verdict, a confidence score (0.0-1.0), and the suspected commit SHA if confidence is high enough.

04

Alert carries context

The change detail page shows the verdict, a link to the suspected commit on GitHub, and the full candidate commit list for manual review. Alerts you ship to Slack or email can embed the verdict too.

In practice

What the verdict actually looks like.

Header renamed95% confidence
- <a href="/signup">Sign up</a>
+ <a href="/pricing">Pricing</a>

Candidate commit: fix: rename hero link to Pricing in Header.tsx (jane, 3 min ago)

Verdict:Likely commit abc1234 caused the change, as renaming the hero link to Pricing in Header.tsx directly matches the observed href and label updates.

Price dropped35% confidence
- $99/month
+ $89/month

Candidate commit: bump deps (bot, 8 min ago)

Verdict:Possibly commit def9876 - but the commit message doesn't mention pricing, so the match is weak. Check the CMS publish log before reverting.

No commits0% confidence
- Old Intercom widget
+ Intercom 5.3 (new CSS)

Candidate commit: (none in the last 15 minutes)

Verdict:No commits to the configured repo in the window before this change. Likely a third-party script update or CMS publish.

What you get

The full feature surface.

GitHub correlation

Configure github_repo + a read-only PAT per monitor. We query the commits API for the window around each change and hand the list to the model. Read-only scope is enough; no repo writes ever.

Claude verdict + confidence

Verdict sentences read like "Likely commit abc1234 caused the change, as renaming the hero link to Pricing in Header.tsx directly matches the observed href and label updates." Confidence ≥ 0.8 only when diff content obviously matches the commit.

Suspected commit deep-link

One click jumps from the OnChange alert to the GitHub commit page. Paired with the change diff we already store, you can revert in 30 seconds instead of 30 minutes.

Fails safely

No GitHub config? Attribution still runs and records "no signal found - configure your repo to enable matching". Model times out or returns garbage? The change, the diff, and the alert all go out anyway. Attribution never blocks the critical path.

Full evidence JSON

Every attribution record stores every candidate commit with SHA, short SHA, message, author, timestamp, and URL. Useful if you don't trust the LLM verdict on a particular change and want to review the raw signal.

No workflow change

Attribution lives on the existing change-detail page and in the existing timeline endpoint. If you already use OnChange, enabling attribution is a single PATCH to add github_repo + github_token to a monitor.

FAQ

Questions teams ask before turning it on.

How does OnChange find the right commit?

For each detected change we query the GitHub Commits API for the configured repo, restricted to the 15-minute window before the change was detected (configurable via ATTRIBUTION_LOOKBACK_MINUTES). The resulting commit list is passed to Claude along with the observed diff. The model returns a verdict sentence, a confidence score, and the best-match commit SHA.

What if I don't use GitHub?

GitHub is the v1 source. Deploy correlation for GitLab, Bitbucket, and self-hosted Git providers is on the roadmap. CMS publish detection (Contentful, Sanity, WordPress) and third-party script version tracking are also planned and will populate the same evidence JSON so the UI stays consistent across signal types.

Do I need to give OnChange write access to my repo?

No. The PAT we ask for only needs the read-only "repo" scope - enough to list commits on public and private repos. OnChange never pushes, creates branches, or opens pull requests. The token is stored encrypted at rest and scoped to a single monitor; revoke in GitHub at any time.

Is attribution on every plan?

Yes. Like every other OnChange feature, causal attribution ships on every plan - Free through Enterprise. The paid tiers differ only in monitor count and check frequency, not feature access.

How accurate are the verdicts?

We calibrate the prompt so confidence ≥ 0.8 requires an obvious match between the diff content and the commit message or subject (e.g. "rename hero link" in the commit, matching href and label changes in the diff). Confidence 0.3-0.6 signals a weak circumstantial match - UI should treat these as hints, not conclusions. Below 0.3 the verdict is "no clear match" and the UI suggests manual review.

Does the LLM see my source code?

No source code is sent to Claude. We pass only the commit SHA, first-line commit message (truncated to 140 chars), author name, and the diff OnChange already detected on the monitored page. Nothing else leaves your repo.

Every deploy should answer its own questions.

Turn on attribution for any monitor in under a minute. Free plan includes 5 monitors and every feature.

No credit card required