OnChange correlates every detected change with your recent commits. The alert names the likely cause, the suspected commit, and a confidence score, so debugging production regressions takes seconds instead of hours.
Change attribution
acme.com/header
- <a href="/signup">Sign up</a>+ <a href="/pricing">Pricing</a>
Suspected commit
abc1234
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.
The problem
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.
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.
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
OnChange polls your monitored page. When the text, visual, or API diff crosses your threshold, a Change record is created - same as today.
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.
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.
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
- <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.
- $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.
- 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
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.
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.
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.
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.
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.
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.
Frequently asked questions
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.
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.
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 encrypted at the application layer before storage and scoped to a single monitor; revoke in GitHub at any time.
Attribution can be configured on any monitor. The AI verdict step uses your plan's daily AI budget, which is available on paid plans, so Pro and up get attribution verdicts on their changes.
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.
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.
Turn on attribution for any monitor in under a minute. Free plan includes 5 monitors, no credit card required.