sentry-errors — Auto-Triage Subagent for Sentry

What sentry-errors Actually Does

The sentry-errors subagent is a single-purpose Claude Code agent that turns a noisy Sentry event stream into an ordered action list. It calls the official Sentry MCP tools (mcp__sentry__*), fetches the last 24 hours of issues, groups them by culprit (file plus function) and root-cause hash, then prints a fixed-format digest with three priority buckets and last-touch commits. The agent is read-only by design — it does not open issues, file pull requests, silence alerts, or attempt fixes. According to Sentry's official MCP documentation, the server exposes find_issues, get_issue_details, search_events, and related tools that subagents can compose into triage workflows (Sentry MCP docs).

This pattern was popularized by Boris Cherny, who described using a Sentry MCP plus a triage subagent to "fetch and triage error logs autonomously" while he focuses on coding work. The Pragmatic Engineer interview with Cherny (Building Claude Code with Boris Cherny) confirms subagents are Anthropic's recommended primitive for delegating recurring inbox tasks. The TokRepo entry packages that idea as a single Markdown file you can drop into any repo.

Quick Install in Under 2 Minutes

Four-step bootstrap, mirroring the official Claude Code subagent layout described in Anthropic's subagent docs:

1. Install the Sentry MCP first (TokRepo workflow id 665) — without it, the subagent has no data source.
2. Save the agent file to .claude/agents/sentry-errors.md in your repository.
3. Restart Claude Code or run /agents reload to register the new subagent.
4. Each morning, prompt: "Use sentry-errors to triage what came in overnight."

Claude Code dispatches the subagent, which then calls Sentry MCP, groups events, and returns the digest as a single message. The author reports setup takes under 2 minutes once Sentry MCP is configured, and the subagent file itself is roughly 60 lines of Markdown plus YAML frontmatter.

The Exact Subagent File

The full prompt template lives in .claude/agents/sentry-errors.md and ships verbatim in this skill. Frontmatter declares the tool whitelist:

---
name: sentry-errors
description: Pull recent Sentry errors, group them by component and root cause, suggest priorities. Use for morning triage or after a deploy.
tools: mcp__sentry__*, Bash, Read
---

The body specifies a 6-step workflow the subagent must execute on every invocation:

1. Fetch errors from the last 24h via Sentry MCP (list_issues or list_events with dateFrom = 24h ago).
2. Group by culprit (file plus function) and root-cause hash.
3. For each group, capture: count, first/last seen, affected users, any new release link.
4. Score priority using volume, user impact, and release proximity.
5. For P0 + P1 groups, attach a one-line hypothesis and the most-recent commit that touched the culprit file (git log -1 --format='%h %s' -- <file>).
6. Emit the report in the fixed output format below.

Because tools is restricted to the Sentry MCP namespace plus Bash and Read, the subagent cannot accidentally write code or push commits — that boundary aligns with the principle of least privilege described in MDN's Web Security guidance.

How Priority Scoring Works

The rules are explicit, deterministic, and tunable in the same Markdown file:

The thresholds are intentionally conservative. The Google SRE Workbook recommends prioritizing pages by user impact and recency rather than raw count (Google SRE Workbook, Alerting on SLOs), and the P0 rule requires all three signals to fire before paging. P1 is the most common bucket on a healthy service; P2 collapses into a one-line summary so the digest stays scannable.

If you run a low-traffic product, edit the numbers — for a 50-user beta, change > 100 occurrences to > 10, and > 10 affected users to > 3. The subagent re-reads the file every invocation, so changes take effect immediately.

The Morning Digest Output Format

sentry-errors always emits exactly this shape so downstream tooling (Slack bots, daily standup notes, dashboards) can parse it deterministically:

sentry-errors triage — last 24h
================================
Total events: 1247
Distinct issues: 28
P0: 1 | P1: 4 | P2: 23

P0:
1. src/checkout/charge.ts:88 — 412 events, 87 users, first in v3.4.2
   Hypothesis: Stripe API key rotation broke production
   Last touch: a1b2c3d "Rotate Stripe key"

P1:
1. ...

P2 (collapsed): 23 issues, see Sentry for details.

Three details matter for downstream parsing. The header row is always 4 lines including the divider. The bucket counts use | as a separator for easy awk extraction. The Last touch line is generated locally via git log -1 --format='%h %s' -- <file> rather than from Sentry release metadata, which means even rebased branches surface the right commit.

When to Run It (and When Not To)

Three fits and two anti-fits, derived directly from the skill's prompt template:

Use sentry-errors for:

• Daily morning standup — run before opening any code. Replaces 10–15 minutes of Sentry scrolling with a 30-second digest read.
• Post-deploy 15-minute check — run immediately after pushing to production. The release-proximity rule surfaces regressions before users escalate.
• Active incidents — fastest grouped view of what is breaking right now, with hypotheses to seed your investigation.

Do not use sentry-errors for:

• A specific known error you are already debugging — open Sentry directly, use breadcrumbs and stack traces.
• Long-tail historical analytics — Sentry's UI is purpose-built for this; do not ask a subagent to do BI.

This matches the Anthropic subagents guidance that subagents should have a single, well-defined responsibility rather than acting as general-purpose copilots.

Boundaries and Safety

Three explicit guardrails encoded in the prompt:

1. Do not open issues, file PRs, or fix bugs. The subagent's job ends at the digest.
2. Do not silence or ignore errors in Sentry without explicit user instruction. Read-only by default.
3. Escalate gracefully when Sentry MCP is missing. The subagent prints "Install Sentry MCP first." and stops, rather than hallucinating data.

The tools: mcp__sentry__*, Bash, Read whitelist enforces guardrails 1 and 2 at the harness level — even if the model decides to call Edit, the runner rejects it. Guardrail 3 is enforced inside the prompt and triggers when the MCP tool list is empty.

For read-only triage workflows, this matches the GitHub-recommended pattern for automated bots in GitHub's automation security guide: scope tokens narrowly, never grant write access unless the workflow explicitly needs it.

Customization Recipes

Three common edits, all single-line changes inside the prompt template:

• Scope to one Sentry project. Edit step 1 to list_issues with project=<slug>. Useful for monorepos with one Sentry org but multiple front-ends.
• Stretch the lookback window. Replace dateFrom = 24h ago with 48h ago for Monday-morning runs that need to cover the weekend.
• Lower volume thresholds. Change > 100 occurrences and > 10 affected users to fit a smaller user base. The numbers are not magic — they are the only knobs you tune.

If you want richer output (Slack-formatted blocks, JSON, GitHub issue draft), wrap sentry-errors in a parent agent that calls it first, then post-processes the digest. Do not bake formatting into the subagent — keep its single responsibility intact, per the small-functions principle from the Anthropic engineering blog.

Comparison vs. Vanilla Sentry Workflow

The value is not raw speed — it is consistency. Two engineers running sentry-errors at 9am produce identical digests; two engineers scrolling Sentry produce wildly different priority lists.

Example Session

You:    "Run sentry-errors on overnight events."
Claude: -> Sentry MCP -> fetch 24h
        -> groups 1,247 events into 28 issues
        -> 1 P0, 4 P1, 23 P2
        -> reports:
           P0: src/checkout/charge.ts:88 — 412 events, 87 users, first in v3.4.2
              Hypothesis: Stripe API key rotation broke production
              Last touch: a1b2c3d "Rotate Stripe key"

From prompt to digest, the round-trip is typically under 30 seconds for 1–2k events, dominated by Sentry MCP latency rather than model inference.

How It Fits the Broader TokRepo Skill Library

sentry-errors is one of several read-only triage subagents in the Skill Factory series. It pairs naturally with oncall-guide (incident-response runbook) for live incidents, with code-architect for post-incident reviews, and with loop if you want to run the digest every 4 hours instead of on-demand. The Sentry MCP install workflow (TokRepo id 665) is the only hard prerequisite.

For teams that want the full "Boris Cherny morning workflow," combine sentry-errors with the loop scheduler and the Anthropic-official ralph-wiggum autonomous loop pattern. Each subagent stays single-purpose; the loop primitive owns the cadence.