Catch new Sentry errors from the last 24 hours before users report them

SKILL.md---
name: sentry-new-errors-digest
description: "Every morning: unresolved Sentry issues first seen in the last 24 hours, ranked by users and events, with the release and code they started in. Use when the user asks for this, or when it runs on a schedule."
---

# Sentry new errors digest

Every morning: unresolved Sentry issues first seen in the last 24 hours, ranked by users and events, with the release and code they started in.

New issues are the most useful thing Sentry knows and the easiest to miss once its alerts go to a channel everyone muted. Something that never happened before started happening, usually right after a deploy, and the earlier someone looks, the smaller the fix.

Every morning the agent asks Sentry for issues first seen in the last day, ranks them by users affected, and adds the release they arrived with and the top in-app stack frame. A quiet night gives a short green card; a bad one lands in Needs you.

## Two ways to get the data

Use the API or MCP route when you have an MCP server, a CLI or an API token for the app. Otherwise, if you can drive a browser the user is signed in to (Claude in Chrome, a Playwright or Chrome DevTools MCP server), use the browser route. Say which one you used.

## Route A: API or MCP server

### What you need

- A Sentry auth token with `event:read` and `project:read` (from an internal integration or your user settings) in `SENTRY_AUTH_TOKEN`, plus the org slug.
- Or the Sentry MCP server or connector, signed in to the organization.

If something is missing, say what and stop; do not invent numbers.

### Steps

1. **Query new issues** (Sentry): `GET /api/0/organizations/{org}/issues/?query=is:unresolved firstSeen:-24h&statsPeriod=24h&sort=user&limit=25`, with `project` set to the project IDs you care about. With the Sentry MCP server, search issues with the same query.
2. **Read the details** (Sentry): Keep `shortId`, `title`, `culprit`, `level`, `count`, `userCount`, `firstSeen` and `permalink`. For the top 5, read `GET /api/0/organizations/{org}/issues/{issue_id}/events/latest/` for the release and the top in-app stack frame.
3. **Tie them to releases**: Group new issues by the release they first appeared in, so a bad deploy shows up as one release with several new issues rather than as unrelated errors.
4. **Rank and post**: Rank by users, then events. An issue needs a look at 10 or more users or 100 or more events. Post with `work_state: failed` when any new issue crosses that line, and `done` otherwise.

## Route B: the browser

### What you need

- Signed in to Sentry as a member of the organization with at least the Member role on those projects; SSO-only organizations need the SSO session done first.

If something is missing, say what and stop; do not invent numbers.

### Steps

Start at https://sentry.io/issues/. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears.

1. **Open Issues for the right projects**: The URL opens the Issues page of your last organization; switch with the organization menu in the top left if needed. In the project selector at the top, pick the projects you care about, and set the time range picker to **24H**.
2. **Search for new issues**: Replace the search bar contents with `is:unresolved firstSeen:-24h` and press Enter. Set **Sort** to `Users`. The list now shows only issues that first appeared in the last day, biggest first.
3. **Read the top of the list**: For each row note the short ID, title, level, and the **Events** and **Users** columns. Anything with 10 or more users or 100 or more events needs a look.
4. **Open the top five**: Click each of the top five. On the issue page read **Release** in the tags block and the first in-app frame in the stack trace (toggle **Most Relevant** or **App Only** if the full trace shows). Copy the issue URL from the address bar.
5. **Group by release and judge**: Note which releases brought more than one new issue. Write the digest ranked by users, say which release each issue arrived in, and end with the issue to open first.

Note: The Issues list pages 25 at a time; a very bad night may need the next page. User counts depend on your SDK setting a user; without it, Sentry falls back to IP addresses or shows zero.

## The report

- **New issues** in the last 24 hours, and how many need a look.
- For each: short ID, title, events, users, level, first release and the top in-app frame.
- **By release**: releases that brought more than one new issue.
- The issue to open first, with its link.

## Post it to Briefkin

When `BRIEFKIN_TOKEN` is set, or `~/.config/briefkin/env` exists (the installer from https://briefkin.dev/docs writes it), also send the result to the user's Briefkin board as one card. Keep the `item_key` the same on every run so the card updates in place, use a new `event_id` per run, and put today's real numbers in place of the example ones. If the request fails, say so once and carry on.

```bash
[ -n "${BRIEFKIN_TOKEN:-}" ] || . ~/.config/briefkin/env
curl -sS -X POST "${BRIEFKIN_URL:-https://briefkin.dev}/v1/events" \
  -H "authorization: Bearer $BRIEFKIN_TOKEN" \
  -H "content-type: application/json" \
  -d @- <<'JSON'
{
  "v": 1,
  "event_id": "sentry-new-errors-digest/<date of this run, e.g. 2026-10-16>",
  "item_key": "sentry-new-errors-digest",
  "project": "acme-web",
  "source": "Sentry new errors digest skill",
  "kind": "update",
  "title": "6 new errors since yesterday, 2 need a look",
  "summary": "**ACME-WEB-4F2** hit 212 users after release `2026.10.15-2`. Four of the six new issues arrived with that release.",
  "work_state": "failed",
  "widget": [
    {
      "type": "Table",
      "props": {
        "columns": [
          "Issue",
          "Events",
          "Users",
          "Release"
        ],
        "align": [
          "left",
          "right",
          "right",
          "left"
        ],
        "rows": [
          [
            "ACME-WEB-4F2 TypeError: Cannot read properties of undefined (reading 'plan')",
            1840,
            212,
            "2026.10.15-2"
          ],
          [
            "ACME-WEB-4F7 ChunkLoadError: Loading chunk 812 failed",
            655,
            148,
            "2026.10.15-2"
          ],
          [
            "ACME-WEB-4F5 RangeError: Invalid time value",
            41,
            9,
            "2026.10.15-2"
          ],
          [
            "ACME-WEB-4F8 Error: Stripe.js failed to load",
            12,
            7,
            "2026.10.15-2"
          ],
          [
            "ACME-WEB-4F9 AbortError: The user aborted a request",
            38,
            6,
            "2026.10.15-1"
          ],
          [
            "ACME-WEB-4F3 SyntaxError: Unexpected token '<'",
            4,
            2,
            "2026.10.14-3"
          ]
        ]
      }
    },
    {
      "type": "KeyValue",
      "props": {
        "items": [
          {
            "key": "Top frame of 4F2",
            "value": "app/billing/PlanBadge.tsx:18 in PlanBadge"
          },
          {
            "key": "First seen",
            "value": "Oct 15, 16:42 UTC"
          }
        ]
      }
    },
    {
      "type": "Links",
      "props": {
        "items": [
          {
            "label": "ACME-WEB-4F2 in Sentry",
            "url": "https://acme.sentry.io/issues/5123456789/"
          }
        ]
      }
    }
  ]
}
JSON
```

Widgets come from the Briefkin catalog (https://briefkin.dev/v1/catalog). Without a token, just give the user the report.

## Run it on a schedule

Suggested: Every day at 8:00 (`0 8 * * *`). From cron, with the agent signed in on that machine:

```bash
0 8 * * * claude -p "Run the sentry-new-errors-digest skill"
# Codex: codex exec, Gemini CLI: gemini -p, Copilot CLI: copilot -p, OpenCode: opencode run
```

Or use the agent's own scheduler (Claude Code routines, Codex automations, Claude or ChatGPT scheduled tasks): https://briefkin.dev/skills/sentry-new-errors-digest#schedule

Source: https://briefkin.dev/skills/sentry-new-errors-digest