Sentry → GitHub workflow: pull high-priority Sentry issues and automatically create GitHub issues

[Al629176]

Summary

Build a workflow that periodically fetches high-priority issues from Sentry, filters by severity/frequency/priority, and automatically creates corresponding GitHub issues in the relevant repo — keeping the engineering team's bug backlog in sync with what Sentry is actually seeing in production without manual triage overhead.

Problem

High-priority errors surfaced in Sentry are often not acted on quickly because they require a developer to manually check Sentry, decide it's worth filing, copy the details, and create a GitHub issue. This manual step means critical issues can sit in Sentry untracked on GitHub for days. An automated workflow closes that gap.

Solution

A scheduled (or webhook-triggered) workflow that:

1. Queries the Sentry API for unresolved issues above a priority/frequency threshold
2. Deduplicates against existing open GitHub issues (don't create duplicates)
3. Creates a well-formatted GitHub issue for each new Sentry issue, with all relevant context
4. Optionally assigns priority labels and links back to the Sentry issue URL

---

Workflow steps

1. Fetch from Sentry

• Query Sentry API: unresolved issues, filtered by:
  • Priority: critical and high (configurable)
  • First seen: within the last N hours (configurable, default 24h)
  • Minimum event count or user count threshold (configurable)
• Supported trigger modes:
  • Scheduled: run every hour / every 6 hours via cron
  • Webhook: Sentry alert webhook fires the workflow in real time

2. Deduplicate

• Before creating a GitHub issue, check if one already exists for this Sentry issue ID
  • Store a mapping of sentry_issue_id → github_issue_number in workflow state
  • Or search GitHub issues for a tag/label containing the Sentry issue ID
• Skip if a GitHub issue already exists (open or closed)

3. Create GitHub issue

Each created GitHub issue should include:

• Title: [Sentry] <Sentry issue title>
• Body:
  • Sentry issue URL (direct link)
  • Error type and message
  • First seen / last seen / event count / affected users
  • Top stack frame (file + line)
  • Sentry project and environment (production / staging)
  • Reproduction steps if available from Sentry's context
• Labels: bug, sentry, and a priority label (priority: critical / priority: high)
• Repo routing: map Sentry project name → GitHub repo (e.g. openhuman-rust → tinyhumansai/openhuman, backend → tinyhumansai/backend)

4. Comment back to Sentry (optional)

• Post a comment on the Sentry issue with the GitHub issue URL so the two are cross-linked

---

Implementation checklist

• Sentry API integration: auth token stored in secrets, query /api/0/projects/{org}/{project}/issues/
• Priority/frequency filter configurable via workflow parameters
• Deduplication logic (state store or GitHub issue label search)
• GitHub issue creation node with the structured body format above
• Sentry project → GitHub repo routing table (configurable, not hardcoded)
• Sentry back-comment node (optional, behind a config flag)
• Scheduled trigger (cron) wired up
• Webhook trigger mode supported
• Dry-run mode: logs what would be created without actually creating issues

Acceptance criteria

• A critical Sentry issue appearing in production automatically creates a GitHub issue within one workflow cycle
• Running the workflow twice for the same Sentry issue does NOT create a duplicate GitHub issue
• GitHub issue contains Sentry URL, error details, event count, and stack frame
• Priority label on GitHub issue matches Sentry priority
• Repo routing works correctly (Sentry project maps to the right GitHub repo)
• Dry-run mode confirmed working
• Tested end-to-end against a real Sentry project in staging

Related

• Automate Discord → GitHub issues pipeline: openhuman #3675
• Social media workflow (same orchestration framework): tinyhumansai/tinyflows (companion issue)
• Sentry is already integrated in the backend: src/config/sentry.ts