How to have Claude Code find, fix and resolve production errors
Connect Runheed to Claude Code, then ask "what broke in production since the last deploy?" Claude calls runheed_get_recent, reads the stack trace with runheed_get_error, edits the code in your repo, and after you commit it marks the error resolved with the commit hash. If the error happens again, it reopens on its own.
The loop, step by step
- Your app reports an exception through the SDK. Repeats of the same error are grouped by fingerprint, with a count and first and last seen times.
- You ask Claude Code what broke. It calls runheed_get_recent or runheed_search_errors and picks the error with the most events or the newest one.
- It calls runheed_get_error for the stack trace, breadcrumbs and recent events, and runheed_get_error_context when it needs the request, release or environment.
- It opens the files in the stack trace, reproduces the failure (ask it to write a failing test first), and fixes it.
- After you commit, it calls runheed_resolve_error with the commit hash as the note. If the same error comes in again, the group reopens and shows up in the next "what broke" question.
Prompts that work
- "What broke in production since the last deploy? Fix the top one and resolve it with the commit hash."
- "Find unresolved TypeErrors in the checkout project and tell me which file each one comes from."
- "Did errors go up after yesterday's deploy? Compare the last 24 hours with the last 7 days."
- "Write a failing test that reproduces the top error before you change any code."
- "Ignore the bot 404s on /wp-login.php so they stop showing up."
Asking for a failing test first keeps the agent from "fixing" a symptom: the test proves it understood the error, and it stays in your suite after the error is resolved.
Run a triage report without opening a session
Claude Code's print mode (claude -p) runs one prompt and exits, which suits a morning report or a CI job. Allow only the read tools so the run cannot change anything:
claude -p "Use runheed to list unresolved production errors from the last 24 hours. For the top three, give the file and line from the stack trace and a one-line guess at the cause." \
--allowedTools "mcp__runheed__runheed_get_recent" "mcp__runheed__runheed_get_error" "mcp__runheed__runheed_get_trends" \
> triage.mdFor unattended runs on a CI box, add the local server with an agent key (claude mcp add runheed --env RUNHEED_API_KEY=al_... -- npx -y https://runheed.com/dl/runheed-mcp-0.1.0.tgz) so no browser sign-in is needed. Agent keys are created in Settings and can be revoked there at any time.
Which permissions Claude Code needs
Claude Code asks before it calls an MCP tool the first time. The read tools are runheed_get_recent, runheed_search_errors, runheed_get_error, runheed_get_error_context, runheed_get_trends and runheed_get_project_health. The three that change state are runheed_resolve_error, runheed_ignore_error and runheed_unignore_error, and each only changes an error's status, which can be flipped back. None of them can touch your code, your servers or your billing.
The full tool list with example questions is on the MCP server page.
Questions
- Can Claude Code fix production bugs on its own?
- It can read the errors, draft the fix and resolve the error, but Runheed cannot deploy anything. The change goes through your normal commit, review and deploy, so you decide what ships.
- What happens if the fix did not work?
- A resolved error that occurs again reopens on its own, with the new events attached, so the next "what broke" question brings it back to the top.
- Does the same loop work in Cursor or Codex?
- Yes. The tools are the same in every MCP client. Only the setup differs; each client has a page under Connect your agent.
- Which languages does it work for?
- The SDKs cover Node.js and TypeScript (including Next.js and Express) and Python (including FastAPI, Django and Flask). Any other language can post JSON to the ingest endpoint.