Sentry to GitHub Issue Automation (with Dedupe) | General Input

Build me an agent workflow that runs on a cron every 30 minutes and converts recurring production errors in Sentry into actionable, deduped GitHub issues, with a Slack ping to engineering.

Trigger: cron, every 30 minutes.

Step 1. Use the Sentry List Organization Issues operation to fetch unresolved, high-frequency, recent issues from my Sentry organization. Sort by frequency, only include issues with status unresolved, and limit to issues that have been seen in the last 24 hours. Filter to a configurable minimum event count (default 10) so we ignore one-off noise.

Step 2. For each Sentry issue returned, use the GitHub Search Issues and Pull Requests operation against the target repo to look for an existing tracking issue. The search query should look for a marker string of the form sentry-issue-id:<id> in the issue body, scoped to the configured repo. If a match comes back, skip the Sentry issue entirely. This dedupe step is the whole point of the workflow, so do not skip it.

Step 3. For each Sentry issue with no existing tracking issue, use the Sentry List an Issue's Events operation to pull a single representative event so we can include the stack trace and breadcrumbs in the GitHub issue body.

Step 4. Use the GitHub Create an Issue operation to file a tracking issue in the configured repo. The title should be a short, human-readable summary of the error (error type plus the top frame). The body should include: the occurrence count, the number of affected users, the environment, a permalink back to the Sentry issue, the stack trace inside a fenced code block, the most recent breadcrumbs, and a final line containing the dedupe marker sentry-issue-id:<id> so future runs can find it. Keep the marker on its own line at the bottom of the body.

Step 5. Use the GitHub Add Labels to an Issue operation to attach a from-sentry label to the new issue. If the label does not exist yet, that is fine, surface a clear error and stop on that issue.

Step 6. Use the Slack Send a Message operation to post a short alert to the engineering channel. Include the error title, the occurrence count, the affected user count, a link to the new GitHub issue, and a link back to the Sentry issue. One Slack message per newly filed GitHub issue, not a digest.

Configurable inputs: Sentry organization slug, optional Sentry project filter, GitHub repo (owner/name), Slack channel ID, minimum event count threshold, and time window for unresolved issues.

Integrations to use: Sentry, GitHub, and Slack. Do not introduce other services.

Additional information

What does this prompt do?

Pulls unresolved, high-frequency Sentry issues from your organization on a 30-minute cron.
Searches the target GitHub repo for an existing tracking issue using the Sentry issue ID as a marker, so duplicates never get filed.
For new errors, grabs a representative event with stack trace and breadcrumbs and opens a GitHub issue with occurrence count, affected users, and a link back to Sentry.
Applies a from-sentry label to every filed issue and posts a Slack alert to the engineering channel.

What do I need to use this?

A Sentry account with an auth token that has org:read, project:read, and event:read scopes.
A GitHub account connected with permission to read and create issues in the target repo.
A Slack workspace connected and a channel ID where alerts should land.
The Sentry organization slug, the GitHub repo (owner/name), and the Slack channel ID configured before the first run.

How can I customize it?

Change the cron cadence (every 15 minutes, hourly, etc.) or the Sentry filters (event count threshold, time window, environment, project).
Route different Sentry projects to different GitHub repos or Slack channels by branching on the project slug.
Tweak the issue template, labels, assignees, or milestone applied to filed issues.

Frequently asked questions

How does the dedupe actually work?

Every filed GitHub issue embeds a marker line containing the Sentry issue ID. On each run the agent uses GitHub Search Issues and Pull Requests to look for that marker in the target repo before creating anything, so the same Sentry issue never gets filed twice.

What counts as a high-frequency error?

By default the agent asks Sentry for unresolved issues sorted by frequency in the recent window. You can tune the threshold (event count, affected users, time range) in the prompt to match how noisy your Sentry org is.

Can I send different Sentry projects to different GitHub repos?

Yes. Tell the agent which Sentry project slugs map to which GitHub repos and it will route accordingly. You can do the same thing with Slack channels.

Will this resolve issues in Sentry when the GitHub issue closes?

Not in this workflow. It only handles the create direction. You can layer a second workflow that listens for closed GitHub issues with the from-sentry label and resolves the matching Sentry issue.

Does the GitHub issue include the stack trace?

Yes. The agent pulls a representative event from Sentry with List an Issue's Events and embeds the stack trace in a fenced code block, plus a link back to the Sentry issue for full breadcrumbs and context.