/code DevIntern + Sentry
Point the workspace worker at your Sentry projects and it turns unresolved error groups into pull requests: isolated worktree, coding agent, tests, and a fix routed to the repository that owns the code.
How it works
What DevIntern does with Sentry
Each product path keeps Sentry as the handoff surface. No rip-and-replace, no new dashboard.
/code Fix production errors end-to-end
- 1 Add an [[error_monitors]] entry per Sentry project in workspace.toml, mapped to the repository that owns the code.
- 2 The workspace worker polls for unresolved error groups and dispatches the ones that cross your occurrence threshold.
- 3 The agent runs the normal fix pipeline: worktree, implementation, tests, commit, and pull request.
Capabilities
Built for real Sentry workflows
Sentry API polling with a personal auth token (event:write)
Repo routing: every monitor maps to the repository that owns the code
Occurrence threshold (min_occurrences) and per-tick cap (max_per_tick)
Optional best-effort comment back on the Sentry issue after each run
Self-hosted Sentry via a configurable base_url
No generic feasibility gate: the watcher supplies concrete runtime evidence
A single run
From Sentry error group to a pull request ready for review
A single run takes an unresolved Sentry error group from threshold to pull request ready for review. The watcher applies the actionability checks up front, so dispatched errors go straight to implementation.
- 1
An error crosses the threshold
The worker polls each configured Sentry project on its poll_interval. An error is eligible once it meets min_occurrences (default 5) and carries a title plus a culprit, exception type, or filename. At most max_per_tick (default 3) errors are dispatched per poll.
- 2
Dispatch to the owning repository
Each monitor maps to a repo (required in multi-repo workspaces) and optionally a team, so the fix inherits that team's environment. An isolated worktree is prepared the same way as tracker-backed runs.
- 3
The agent implements the fix
Because the watcher already attached concrete runtime evidence, the run skips the generic task feasibility assessment and proceeds directly to implementation, then runs your tests and commits on a feature branch.
- 4
Pull request and write-back
The fix lands as a pull request, and the run is recorded with an error_monitor origin in the dashboard. With comment_on_action = true, a short comment is left on the Sentry issue after the run. A failed fix is never automatically repeated; deferred runs retry on a later poll.
What gets written back to Sentry
Run outcomes land on the Sentry issue as short comments when comment_on_action is enabled. Comments are best effort and never change the run outcome or the issue status.
Successful remediation
Short comment noting the fix ran, best effort
Failed remediation
Short comment noting the run failed; no automatic retry
Dashboard
Every run recorded with an error_monitor origin and its PR link
Sentry specifics at a glance
Config
One [[error_monitors]] entry per project in workspace.toml
Auth
SENTRY_AUTH_TOKEN personal auth token with event:write access, plus organization and project slugs; a DSN will not work
Eligibility
min_occurrences (default 5) plus a title and culprit, exception type, or filename
Pacing
max_per_tick (default 3) per poll; poll_interval defaults to [defaults].poll_interval
Self-hosted
base_url points the monitor at an on-premise Sentry instance
Credentials
Per-monitor env_file or [error_monitors.env], layered on top of workspace and team credentials
Applying changes
Monitors are validated by live reload but need a worker restart to take effect
Get connected
Setup guides and configuration
Credentials stay in project-local .env files. DevIntern runs on your machine or server, not a shared implementation cloud.
FAQ
Common questions about Sentry
What credentials does the Sentry integration need?
A personal auth token with event:write access, stored in the monitor's env_file, plus the organization and project slugs in workspace.toml. A Sentry DSN will not work: a DSN sends events into Sentry, while polling issues requires an auth token.
Does a multi-repo worker know where to send each fix?
Yes. Every [[error_monitors]] entry maps to a repo. It may be omitted only when the workspace has exactly one repository; in a multi-repo workspace it is required, so the worker never guesses. An optional team key inherits that team's environment.
Does DevIntern change the Sentry issue status?
No. Issue statuses stay yours to manage. With comment_on_action = true, DevIntern leaves a short best-effort comment after a run, but comments never change the issue status or the run outcome.
What happens when a fix fails?
The run is recorded as failed and the error is not automatically repeated. A run deferred because the repo or agent is busy is released and retried on a later poll. Handled issue IDs are deduplicated per Sentry project in the workspace database.
Is self-hosted Sentry supported?
Yes. Set base_url on the monitor to point at your on-premise Sentry instance. The provider contract is shared, so future error monitors (such as Datadog) will use the same polling, deduplication, and routing.
Try DevIntern with Sentry
Connect Sentry, run your first workflow, and keep the trackers, repos, and reviewers your team already trusts.
Free for interactive use · FSL source-available · BYO model keys