KeelenIntegration · Sentry
Sentry catches the error. Keelen prepares the work.
Keelen's Sentry integration logs production issues. They arrive from your webhook. It only files work when you turn filing on, and then chosen issues become budgeted roadmap Requests. That work follows your project's workflow. Your merge policy applies too. Keelen also watches the issue's last seen time in Sentry. That time settles the issue.
It is built for the pager. A transient noise list and hard budgets mean at most 5 errors a day per project become work by default, ranked fatal first. At most 3 fixes in flight per project at a time. Iterations meter on your Keelen plan, and engine tokens bill to your provider at cost.
- A chosen issue becomes a Request on your roadmap. Keelen budgets it. Then your project workflow runs it.
- Triage ranks by severity. Fatal and frequent errors come first. Stale noise comes later.
- Settlement watches whether Sentry reports the issue as quiet. It does not prove that a code change caused the result.
- Filing is budgeted at 5 a day per project by default. Later work still uses plan iterations. It also uses any provider tokens. Those are the tokens you set up.
How selected Sentry issues become reviewed work
Connect your Sentry project
In your Keelen project's Settings, fill in four fields. Three are required and the fourth is optional. They are 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 set in the UI and cannot be read back. They are encrypted at rest. Then add Keelen's webhook URL to that same internal integration in Sentry. Turn filing on for the project. Until you do, Keelen records issues without filing work.
An error fires
Sentry delivers the issue webhook. Keelen checks the HMAC signature against your secret and logs the issue in a ledger. The webhook itself never starts work. An error flood costs rows instead of machines.
Triage, on a budget
The loop drops transient noise. It folds repeat clusters into one. It ranks what is left fatal first, then by event count and recency. Survivors file onto your roadmap as ordinary requests. That happens at most 5 a day per project by default.
The project workflow handles the Request
Intake sorts the Request. Planning then sets the tasks and what counts as done. Ready runs change code in isolated VMs, using the AI accounts you connected. You review the pull request and its proof. Test proof needs a test command that runs, and merge then follows your required checks and project policy.
Keelen observes the issue after terminal work
After work reaches a terminal state, Keelen polls your Sentry with your auth token, every 6 hours by default. It watches the issue's live last seen time. 72 quiet hours settle the observation. A regression signal from Sentry reopens it. Once the error has come back three times, Keelen parks it for you.
It will not flood you
Error monitors love to page you, and an error fixer could spam you just as fast. Keelen treats your attention and your iteration budget as scarce. 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. You can ask us to tune those numbers. If fixes stop landing, an unproductive breaker pauses filing and releases itself later. So the loop never grinds your iterations against a lost cause.
It observes whether the issue stays quiet
Settlement polls your Sentry with your token and checks the issue's live last seen time. It records a quiet observation after 72 hours, giving up after 30 days. This is evidence about error recurrence. It is not proof that a code change caused a production fix. If Sentry flags the issue unresolved again, the work reopens. Once the error has come back three times, Keelen parks it for you. Writing back into your Sentry ships off, so Keelen does not mark your issues resolved. Turning it on is an operator option we enable on request. It is not a switch in your project settings.
Sentry Seer capabilities
Sentry documents Seer as a process that fixes issues. You can set where it stops. Check Sentry's current docs for the options your group has.
Security and data handling
Your webhook URL carries a token that is hard to guess. It is unique per project. Every delivery must pass an HMAC signature check against your secret. Keelen pulls a strict list of fields into its ledger. The list holds the issue id, project slug, a masked title, the culprit and exception type, the severity level, event counts, first and last seen times, and an https permalink. Keelen then caps their size. It also records a delivery count and a cluster signature. Keelen works out both itself rather than reading them from 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. It is never logged. Your Sentry secrets are encrypted at rest. They 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 documents Seer with stages you can set. They run from finding the cause to opening a pull request. Keelen takes selected Sentry issues into its own budgeted Request workflow. You can use both tools together.
What you get
Seer · Configurable analysis, solution, code change, or pull request stages
Keelen · Budgeted roadmap Request. Code and review follow your project workflow.
Where it works
Seer · Inside Sentry, at triage time
Keelen · In your delivery loop, with your roadmap, tasks, and isolated VMs
Test proof
Seer · Depends on the selected Seer stage and repository setup
Keelen · Depends on the resulting project's configured workflow
Review before merge
Seer · Depends on the selected Seer stage and repository setup
Keelen · Your project's configured review and merge policy
Sentry issue observation
Seer · Issue state and evidence remain in Sentry
Keelen · 72-hour quiet settlement signal, not proof of a code fix
Seer abilities and stopping points can change. Sentry docs were reviewed on September 11, 2026. Keelen's column describes how it files and settles work. It is not a promise of a pull request, merge, or fix.
Connect Sentry in about ten minutes
Create a project. Fill in four fields from Sentry, three required and the fourth optional. Then turn filing on. Selected production issues can then become budgeted roadmap Requests for your project's workflow.
FAQ
Which Sentry plans does the Keelen integration work with?
Keelen reads Sentry's standard issue webhooks. They cover issues that are created, resolved, archived, and unresolved. You send them from an internal integration. You create that in your Sentry organization. Keelen does not need Sentry's raw error event stream, since Sentry limits that stream to higher tiers. Some Sentry plans can send these webhooks. If yours can, it can drive Keelen.
What does Sentry-filed work cost?
There is no fee for each error. The iterations that triage, plan, and fix an error meter against your Keelen plan like any other work. Engine tokens bill to your own provider account at cost. Keelen never marks up tokens. Daily filing budgets limit how much error work can start. Once filed, work uses the plan iterations and any provider tokens you set up that it needs.
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. Candidates rank fatal first, then by event count and recency, so the worst error files first.
Can I review fixes before they merge?
Yes. Work that Keelen files from Sentry follows the project's merge policy like any task. Gated auto-merge waits for a review window. With manual merge, Keelen opens the pull request and leaves the button to you. Branch-only opens a branch instead. The plan review gate applies too, so you can require sign off on the plan before any code is written.
How does Keelen observe whether an issue recurs?
After work reaches a terminal state, Keelen polls the issue's live last seen time with your auth token, every 6 hours by default. It settles the observation after 72 quiet hours, stopping after 30 days. This is evidence about recurrence. It is not proof that a code change fixed the issue. If Sentry reports the issue unresolved again, the work reopens. Once the error has come back three times, Keelen parks it for you.
Does Keelen write into my Sentry?
No, not by default. Keelen only reads. It checks the webhooks you send and polls the issues it watches. Writing resolved issues back into your Sentry is optional. It ships off, and we enable it on request. It is not a switch in your project settings. Your Sentry stays the system of record.
What error data does Keelen store?
Keelen stores a small extract with a strict field list and a size cap. It holds the issue id, project slug, title, culprit, and exception type. It also holds the severity level, event counts, first and last seen times, a delivery count, a cluster signature, and an https permalink. Some fields are masked. If the error is filed as work, that record also carries a masked exception message and up to five masked in app stack frames. That is the text an AI iteration reads. The raw webhook payload is never stored. It is never logged. Your secrets are encrypted at rest. No Sentry secret ever reaches an AI iteration's environment.