KeelenIntegration — Sentry
Sentry catches the error. Keelen ships the fix.
Keelen's Sentry integration turns production errors into merged fixes. Connect your Sentry project with a webhook; when a new issue fires, Keelen files it on your roadmap, plans the fix with acceptance criteria, implements it in an isolated single-use VM on your own Claude, Codex, GLM, or Kimi credentials, verifies it through test and review gates, opens a pull request — and then polls your Sentry until the error actually stops appearing.
It is built for the pager, not the demo: a transient-noise list and hard budgets mean at most 5 errors a day per project become work (by default), ranked fatal-first, with 3 fixes in flight per project at a time. Iterations meter on your Keelen plan; engine tokens bill to your provider at cost.
- An error you never triaged arrives as a pull request with tests — not another ticket.
- Triage ranks severity first: fatal, high-frequency errors file before stale noise.
- The loop confirms the fix in production: it polls your Sentry until the error goes quiet.
- A bad deploy costs database rows, not AI spend — filing is budgeted at 5 a day per project by default.
How Sentry errors become merged fixes
Connect your Sentry project
In your Keelen project's Settings, fill in four fields — three required, the fourth optional: your Sentry organization slug, the project slug to watch, the integration's client secret, and an auth token. Without the auth token, Keelen still files work, but it can only close an error out when Sentry itself marks the issue resolved. Secrets are write-only in the UI and encrypted at rest. Then add Keelen's webhook URL to that same internal integration in Sentry, and turn filing on for the project — until you do, Keelen records issues without filing work.
An error fires
Sentry delivers the issue webhook. Keelen verifies the HMAC signature against your secret and records the issue in a ledger — the webhook itself never spawns work, so an error flood costs rows, not machines.
Triage, on a budget
The loop drops transient noise, deduplicates repeat clusters, and ranks candidates fatal-first, then by event count and recency. Survivors file onto your roadmap as ordinary requests — at most 5 a day per project by default.
The loop ships the fix
Intake classifies the error, planning turns it into tasks with acceptance criteria, and a dev iteration implements the fix in an isolated single-use VM on your own engine credentials. The standard gates apply — a red-first test proof, an independent adversarial review, your test suite, CI — and the result is a pull request under your project's merge policy.
Keelen confirms the error stopped
After the fix lands, Keelen polls your Sentry with your auth token — every 6 hours by default — and watches the issue's live last-seen timestamp. Only 72 quiet hours settle the work; a regression signal from Sentry reopens it — until the error has come back three times, after which Keelen parks it for you.
It will not flood you
Error monitors love to page you; an error fixer could easily spam you. Keelen treats your attention and your iteration budget as the scarce resources. A transient-noise list drops known infrastructure blips. Cluster dedup folds repeats into one item. Hard budgets cap filings at 5 per project and 20 per workspace a day, with at most 3 fixes in flight per project — tunable on request. And if fixes stop landing, an unproductive breaker pauses filing and self-releases later, so the loop never grinds your iterations against a lost cause.
It confirms the fix in production
Most AI fixers stop at "pull request opened." Keelen does not trust its own merge. Settlement polls your Sentry — with your token, against the issue's live last-seen timestamp — and only calls the error fixed after 72 quiet hours, giving up after 30 days. If Sentry flags the issue unresolved again, the work reopens — until the error has come back three times, after which Keelen parks it for you instead of silently counting it as shipped. Write-back into your Sentry ships off: Keelen does not mark your issues resolved. Turning it on is an operator-level option we enable on request, not a switch in your project settings.
Security and data handling
Your webhook URL carries an unguessable per-project token, and every delivery must pass an HMAC signature check against your secret. Keelen extracts an allowlist of fields into its ledger — the issue id, project slug, a masked title, culprit and exception type, the severity level, event counts, first- and last-seen timestamps, and an https permalink — then caps their size; it also records a delivery count and a cluster signature, both derived by Keelen itself rather than read out of the payload. When an error is filed as work, that record also carries a masked exception message and up to five masked in-app stack frames. The raw webhook payload is never stored and never logged. Your Sentry secrets are encrypted at rest and are never shown again in the UI. No Sentry secret is ever placed in an AI iteration's environment — the model sees only this scrubbed extract. A delivery whose project slug does not match your connection is dropped.
Keelen and Sentry Seer
Sentry ships its own AI debugging agent, Seer: root-cause analysis and a suggested fix, inside Sentry, right where you triage. Keelen sits on the other side of the handoff — it takes the error out of the queue and returns a tested, reviewed pull request, then verifies in production that the error stopped. Many teams will run both.
What you get
Seer · Root-cause analysis and a suggested fix
Keelen · A tested, reviewed pull request on your repo
Where it works
Seer · Inside Sentry, at triage time
Keelen · In your delivery loop — roadmap, tasks, isolated VMs
Test proof
Seer · Your team validates the suggestion
Keelen · New tests must fail before the fix and pass after
Review before merge
Seer · Human review of the suggestion
Keelen · Independent adversarial review, then your merge policy
Confirms the error stopped
Seer · You watch the issue after applying the fix
Keelen · Polls your Sentry until 72 quiet hours pass
Model credentials
Seer · Bundled with the monitoring product
Keelen · Your own Claude / Codex / GLM / Kimi plan, at cost
The Seer column describes the designed workflow of an in-monitoring AI debugger, not a version-by-version feature audit — check Sentry's docs for current capabilities. The Keelen column is backed by shipped, tested code. The short version: Seer explains the error where you triage; Keelen ships the fix and verifies it.
Connect Sentry in about ten minutes
Create a project, fill in four fields from Sentry — three required, the fourth optional — and turn filing on. The next qualifying production error arrives as a pull request — planned, tested, reviewed, and watched until it goes quiet.
FAQ
Which Sentry plans does the Keelen integration work with?
Keelen consumes Sentry's standard issue webhooks — issue created, resolved, archived, and unresolved — sent by an internal integration you create in your Sentry organization. It does not depend on Sentry's raw error-event stream, which Sentry limits to higher tiers. If your Sentry plan can send issue webhooks from an internal integration, it can drive Keelen.
What does automatic error fixing cost?
There is no per-error fee. The iterations that triage, plan, and fix an error meter against your Keelen plan like any other work, and engine tokens bill to your own provider account at cost — Keelen never marks up tokens. Daily filing budgets cap how much error work can start, so a bad deploy cannot burn your month's iterations.
Will a noisy deploy flood my roadmap?
No. The webhook only records issues; filing runs on a budget — by default 5 errors a day per project, 20 per workspace, and at most 3 fixes in flight per project. A transient-noise list and cluster dedup drop known blips and repeats, and candidates rank fatal-first, then by event count and recency — the worst error files first, not the oldest.
Can I review fixes before they merge?
Yes. Sentry-filed work follows your project's merge policy like any other task: gated auto-merge with a review window, manual merge — Keelen opens the pull request and leaves the button to you — or branch-only. The plan-review gate applies too, so you can require sign-off on the plan before any code is written.
How does Keelen know the fix actually worked?
It asks Sentry, not itself. After the fix lands, Keelen polls the issue's live last-seen timestamp with your auth token — every 6 hours by default — and settles only after 72 quiet hours, stopping after 30 days. If Sentry reports the issue unresolved again, the work reopens — until the error has come back three times, after which Keelen parks it for you.
Does Keelen write into my Sentry?
No, not by default. Keelen only reads: it verifies the webhooks you send and polls the issues it is watching. Marking your Sentry issues resolved is an optional write-back that ships off and is enabled by us on request — it is not a switch in your project settings. Your Sentry stays the system of record.
What error data does Keelen store?
An allowlisted, masked, size-capped extract: the issue id, project slug, title, culprit, exception type, severity level, event counts, first- and last-seen timestamps, a delivery count, a cluster signature, and an https permalink. If the error is filed as work, that record also carries a masked exception message and up to five masked in-app stack frames — the text an AI iteration reads. The raw webhook payload is never persisted and never logged, your secrets are encrypted at rest, and no Sentry secret ever reaches an AI iteration's environment.