In short
To turn production errors into GitHub issues automatically, send each error to RunGuard. It groups duplicates by signature, applies your safety policy, builds a crash packet with the stack trace and suspected files, and files a labeled GitHub issue through your GitHub App installation — then routes it to your own AI coding agent and tracks the fix back to merge.
The RunGuard SDK (TypeScript or Python) or a plain POST /ingest sends the exception, stack trace, and request metadata the moment it happens in production.
Identical signatures collapse into a single incident, so 10,000 occurrences of one bug become one issue — not 10,000. Each group is classified by error type.
Ignore patterns, protected paths, and your plan quota are evaluated before anything leaves RunGuard. Noise and out-of-scope errors never reach your repo.
A structured Markdown packet is assembled: repository, classification, frequency, first/last seen, suspected file and line, and the safety policy that was applied.
RunGuard files a labeled issue in your repo through your GitHub App installation — deduped against existing issues, so a recurring error updates one issue instead of spawning new ones.
When a pull request closes the issue or merges, GitHub webhooks flip the incident to completed and link the PR back to the original error. No manual cross-referencing.
TypeError: Cannot read properties of undefined (reading 'trim')
at parseJSON (/app/src/utils/parse.js:3:22)
at handleSubmit (/app/src/routes/checkout.js:48:12)
at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5)
at next (/app/node_modules/express/lib/router/route.js:144:13)
at /app/src/middleware/auth.js:21:5
at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5)
...Investigate this production error and propose a small, reviewable fix.
Prefer a failing regression test first when reproducible.
Open a PR for review — never auto-merge. Leave an investigation note if confidence is low.
Assign the issue to Copilot’s coding agent and let it open a PR.
File a @claude issue so your own GitHub Actions workflow fires.
Just file the issue with the crash packet — assign a teammate, no AI.
Send each production error to RunGuard from your app (SDK or HTTP). RunGuard groups duplicates, classifies the error, applies your safety policy, builds a crash packet with the stack trace and suspected files, and files a labeled GitHub issue through your GitHub App installation — then keeps that issue in sync as the fix lands.
No. RunGuard is the control plane — it ingests, groups, enriches, applies policy, and routes. The actual code change comes from a coding agent you own (GitHub Copilot or Claude Code Action), running on your own seat or API key. RunGuard never spends your LLM tokens for you.
No. Errors are deduplicated by signature, so a single bug produces one incident no matter how many times it fires. Ignore patterns and protected paths filter out noise before an issue is ever created, and recurring errors update the existing issue instead of opening new ones.
There are first-party SDKs for TypeScript/JavaScript and Python, and any runtime can report errors over plain HTTP to POST /ingest. That covers Node, FastAPI, Django, Flask, and most other server stacks.
A Markdown crash packet: repository and branch, error classification, how often it has fired and when it was first seen, the suspected file and line, a scoped task description, and the safety policy that was applied (protected paths respected, auto-merge disabled).
Safety is enforced before dispatch, not hoped for after. Protected paths are a hard gate, auto-merge is never enabled, and low-confidence work is framed as an investigation rather than a speculative fix. Every change still arrives as a pull request you review.
Connect a repo, drop in the SDK, and watch the next production error land as a scoped GitHub issue.