A production error alert and a fix landing in main are connected by a chain of manual steps most teams do the same way every time: open Sentry, read the stack trace, find the file in GitHub, figure out what changed recently around that line, write the fix, open the PR, and remember to link back to the Sentry issue so it auto-resolves. Every link in that chain is a copy-paste or a context switch. With Sentry MCP and GitHub MCP in the same session, the agent can walk the whole chain — read the real stack trace, correlate it against the real commit history, generate a fix grounded in both — while a human decides whether the fix is right and whether it's safe to ship.
Assume sentry-mcp connected and scoped to one project (SENTRY_PROJECT=webapp), github-mcp-server connected (GITHUB_TOOLSETS=repos,pull_requests), and a fine-grained PAT limited to acme/webapp.
Workflow Overview: Sentry Alert to Deployed Bug Fix via AI
The shape of the loop:
- Error triage — pull the actual error, its stack trace, frequency, and affected release from Sentry, not a paraphrase of the alert email.
- Root cause location — map the stack trace to the actual file and recent commit history in GitHub, to figure out what changed and when.
- Fix generation — write a targeted fix grounded in both the error detail and the surrounding code, not a generic guess at what "probably" causes a null-pointer-shaped error.
- PR with root cause notes — open a PR that documents the actual root cause and links back to the Sentry issue, so the fix's reasoning is legible to a reviewer who wasn't in the debugging session.
This workflow assumes a genuine bug with a knowable root cause — a null reference, a race condition, a bad type coercion. It's a poor fit for errors whose cause depends on production state that isn't visible to either MCP server (a downstream API that's actually down, infrastructure misconfiguration) — recognizing that distinction early in Step 1 saves you from generating a plausible-looking fix for a problem that isn't a code problem at all.
claude mcp list
Tips
- Confirm the error is actually a code-level bug before generating a fix — Sentry surfaces plenty of alerts (timeouts, third-party outages, infra misconfig) that no PR will resolve, and generating a code fix for one wastes a review cycle on the wrong layer entirely.
- Scope the Sentry MCP connection to one project viaSENTRY_PROJECT, mirroring the GitHub PAT's single-repo scope — an org-wide Sentry token in an agent session is broader access than this workflow needs.
- Pull real frequency and affected-release data before prioritizing a fix — an error affecting 0.1% of sessions on a deprecated release behaves very differently in your triage order than one spiking on the current release.
Step 1: Pulling the Sentry Error, Stack Trace, and Affected Release
Start from the actual issue, not a summary someone typed into a Slack message:
> get the details for Sentry issue WEBAPP-PROD-2C4F. Include the full
stack trace, event frequency over the last 24 hours, affected release
version, and any breadcrumbs leading up to the error.
{
"title": "TypeError: Cannot read properties of undefined (reading 'items')",
"culprit": "src/cart/CartSummary.tsx in calculateTotal",
"frequency_24h": 214,
"affected_release": "webapp@2.14.0",
"stack_trace": [
"at calculateTotal (src/cart/CartSummary.tsx:47:19)",
"at CartSummary (src/cart/CartSummary.tsx:22:5)",
"at renderWithHooks (react-dom.development.js:...)"
],
"breadcrumbs": [
{ "category": "navigation", "message": "/cart" },
{ "category": "xhr", "message": "GET /api/cart 200" },
{ "category": "xhr", "message": "GET /api/cart/recommendations 500" }
]
}
The breadcrumbs here are doing real work — the failing recommendations call, immediately before the crash, is a strong lead that the crash isn't purely a frontend bug in isolation. Before jumping to a code fix, correlate this against when it started:
> when did this error first appear, and does its onset correlate
with the webapp@2.14.0 release date or with something else
(a backend deploy, a feature flag change)?
First seen: 2026-08-18T09:14:00Z
webapp@2.14.0 deployed: 2026-08-15T16:00:00Z (3 days before first occurrence)
→ Onset doesn't correlate with the frontend release. Checking for
correlated backend changes is recommended before assuming this is
purely a frontend regression.
That gap between release date and error onset is exactly the kind of detail that keeps this workflow honest — if you'd jumped straight to "fix the frontend null check" without checking timing, you might ship a defensive fix that masks a real backend regression instead of surfacing it.
Tips
- Pull breadcrumbs alongside the stack trace, not just the trace alone — the sequence of events leading up to an error (a failed adjacent API call, a specific user action) often points at the actual trigger faster than the trace's final frame does.
- Check onset timing against your release history before assuming the most recent frontend deploy caused it — a three-day gap between deploy and first occurrence is a signal to look elsewhere, most likely a backend or third-party dependency change.
- Pull 24-hour frequency before prioritizing — a 214-event spike on a checkout-adjacent path outranks a low-frequency error on a rarely-visited settings page, even if the settings-page error looks scarier in isolation.
Step 2: Locating the Bug in GitHub and Generating a Targeted Fix
With the culprit file and line known, correlate it against actual recent history rather than reading the current file in isolation — a fix should account for what changed, not just what the code looks like today:
> get the commit history for src/cart/CartSummary.tsx in acme/webapp
over the last 30 days. Also get the current content of that file
around line 47.
Recent commits touching this file:
- a1b2c3d (5 days ago) "Add product recommendations to cart summary"
- e4f5g6h (12 days ago) "Refactor cart total calculation"
Line 47:
const total = cart.recommendations.items.reduce((sum, i) => sum + i.price, 0);
The recommendations feature landed 5 days ago — inside the gap between the frontend release and the error's first occurrence, and matching the failed /api/cart/recommendations call in the breadcrumbs. This is the actual root cause taking shape: the code assumes cart.recommendations is always populated, but a failed recommendations fetch (that 500 in the breadcrumb) apparently leaves it undefined instead of an empty array.
> show me the code in the commit that added recommendations
(a1b2c3d) — specifically how cart.recommendations gets set
when the API call fails
// From a1b2c3d, src/cart/cartSlice.ts
async function fetchRecommendations() {
try {
const res = await api.get('/cart/recommendations');
return res.data;
} catch {
return undefined; // <- confirmed: falls back to undefined, not []
}
}
Root cause confirmed with actual evidence, not inference. Generate a fix that addresses the real cause — the undefined fallback — rather than just guarding the one call site that happened to crash first:
> fix this at the source: fetchRecommendations should fall back to
an empty array, not undefined, on failure. Also add a defensive
check in calculateTotal in case recommendations is ever undefined
for another reason — belt and suspenders, but fix the actual root
cause first.
// cartSlice.ts
async function fetchRecommendations() {
try {
const res = await api.get('/cart/recommendations');
return res.data;
} catch {
return []; // fixed: empty array, not undefined
}
}
// CartSummary.tsx
const total = (cart.recommendations?.items ?? []).reduce(
(sum, i) => sum + i.price,
0
);
Tips
- Pull commit history for the culprit file before writing a fix — knowing that a specific recent commit introduced the failure mode turns "add a null check" into "fix the actual data contract that broke," which is a more durable fix.
- Fix the root cause (the bad fallback value) and add a defensive check at the crash site, in that order — a defensive check alone treats the symptom and leaves the same bad contract available to break a different call site later.
- Verify the fix addresses the confirmed cause, not just the confirmed symptom — the stack trace tells you where it crashed, the commit history and breadcrumbs together tell you why, and a fix should answer the second question.
Step 3: Opening a GitHub PR Linked to the Sentry Issue with Root Cause Notes
Open the PR with the actual investigation trail included — a reviewer approving this fix should be able to follow the same reasoning without re-doing the Sentry investigation themselves:
> create a branch fix/cart-recommendations-undefined off main,
commit both changes, and open a PR. Title: "Fix cart crash when
recommendations fetch fails (Sentry WEBAPP-PROD-2C4F)".
Body should explain the root cause with the evidence trail:
commit that introduced it, the breadcrumb showing the failed
API call, and why both fixes (source + defensive check) are included.
## Summary
Fixes a crash in CartSummary when the recommendations API call fails.
Sentry: WEBAPP-PROD-2C4F (214 events/24h, affects checkout flow).
## Root Cause
`fetchRecommendations` (introduced in a1b2c3d, 5 days ago) returns
`undefined` on API failure instead of an empty array. `calculateTotal`
assumes `cart.recommendations.items` always exists, causing a TypeError
when the recommendations endpoint returns a 500 — confirmed via Sentry
breadcrumbs showing a failed `/api/cart/recommendations` call
immediately preceding every crash.
## Fix
- `cartSlice.ts`: `fetchRecommendations` now falls back to `[]`, not
`undefined`, on failure (the actual root cause)
- `CartSummary.tsx`: defensive optional-chaining fallback added at the
crash site as a second layer of protection
## Testing
- Reproduced locally by mocking the recommendations endpoint to 500 —
confirmed the crash before the fix, confirmed graceful fallback after
- Existing cart total tests still pass
Fixes WEBAPP-PROD-2C4F
Sentry doesn't auto-detect a GitHub PR reference the way GitHub auto-links a Jira-style key — link it back explicitly on the Sentry side too, so the issue's own history shows the resolution path:
> add a comment on Sentry issue WEBAPP-PROD-2C4F linking to the new PR,
and mark it as "In Progress" if that status is available in this project
Comment added to WEBAPP-PROD-2C4F:
"Fix in progress: https://github.com/acme/webapp/pull/231 — root cause
confirmed as undefined fallback in fetchRecommendations (a1b2c3d)."
Status: In Progress
After merge and deploy, close the loop for real rather than trusting the fix worked because the code looks right:
> once this deploys, check Sentry for new occurrences of
WEBAPP-PROD-2C4F over the next 24 hours. If frequency drops to zero,
resolve the issue. If it's still occurring, don't resolve —
flag it for follow-up.
That last verification step is the one teams skip most often under time pressure, and it's the one that actually confirms the fix worked in production rather than just in review.
Tips
- Write the root cause and evidence trail directly into the PR body, not just "fixes the crash" — a reviewer who can see the commit that introduced the bug and the breadcrumb confirming the trigger can evaluate the fix on its merits instead of taking your word for it.
- Link back to the Sentry issue from a comment on the Sentry side, not just aFixesreference in the GitHub PR — Sentry doesn't parse GitHub PR bodies for auto-linking the way GitHub parses commit messages for Jira keys.
- Verify the fix in production by checking for new occurrences post-deploy before marking the Sentry issue resolved — a merged PR is evidence the fix was attempted, not evidence it worked.
Tips
Tips
- Confirm an alert is a genuine code bug — not infra, not a third-party outage — before generating a fix, using breadcrumbs and timing correlation from Sentry as the deciding evidence.
- Correlate the stack trace against real commit history before writing the fix, and address the root cause (the bad data contract) ahead of any defensive check at the crash site, not instead of it.
- Close the loop on both systems explicitly — root cause notes and aFixesline in the GitHub PR, a linked comment on the Sentry issue — and verify the fix against real post-deploy occurrence data before marking anything resolved.