Recipe: Triage new errors into tracked issues
1min read
TL;DR: When a new error group appears in Sentry, this playbook summarizes it, checks for an existing issue, and creates a Linear or Jira ticket with stack trace, frequency, and suspected owner. Trigger is a monitoring webhook; output is a tracked issue with context.
Who this is for
Engineering teams that want every meaningful error captured as an actionable issue.
What you'll need
- Connectors: Sentry (or your error tracker), Linear or Jira, optional Slack.
- Secrets: Sentry API key, issue tracker API key.
- Trigger: Webhook on new error group / regression.
How to build it with Ask Ballet
- Open the Console on Home.
- Paste the prompt below; set your tracker, project, and labels.
- Review the plan and confirm.
- Connect Sentry and your issue tracker, then add the webhook.
Build a playbook that triggers when Sentry detects a new error group. Summarize the
error (message, top stack frame, affected release, event count, users impacted).
Search Linear for an existing issue referencing the same error fingerprint. If none
exists, create a Linear issue in the Bugs project with the summary, a link to Sentry,
suggested priority based on event count, and the likely owning team from the file path.
Post the issue link back as a comment on the Sentry group.
What the playbook does
- Webhook trigger — receives the new error group.
- HTTP step (fetch details) — pulls stack trace, frequency, and release data.
- Code step (summarize + dedupe key) — builds a summary and fingerprint.
- HTTP step (search) — checks the tracker for an existing issue.
- HTTP step (create/update) — creates the issue and links it back to Sentry.
Variations and tips
- Only create issues above an event-count threshold to cut noise.
- Map file paths to teams in a Code step for accurate routing.
- For criticals, escalate via Incident response and on-call.