Sentry Monitor — Daily Issue Report

Scan the TeamClu Sentry projects for unresolved fatal/high issues, analyze root causes, and report.

Projects

ucar-inc/teamclu (the old Rust slug) does not exist — it was deleted, and sentry issue list 404s on it. teamclu-rust replaced it on 2026-09-04, so that project has no history before then; an empty result there is expected for a while rather than a signal. Re-verify with sentry project list ucar-inc/ --json if a scan errors on an unknown project.

Execution Steps

0. Quota gate — do this FIRST

The org is on Sentry's free tier: 5,000 errors/month, onDemandMaxSpend = 0, billing period resetting on the 19th. When the quota runs out Sentry drops every incoming event silently — from the issue list that looks identical to "no new errors." This has already happened twice (2026-08-17 and 2026-09-02), and the second time the projects sat blind for over two weeks.

Never report "全部正常" without clearing this check.

sentry api "/organizations/ucar-inc/stats_v2/?field=sum(quantity)&groupBy=outcome&category=error&statsPeriod=7d&interval=1d"

Read the accepted and rate_limited series:

• accepted non-zero for the most recent day → ingestion is healthy, continue.
• accepted at 0 with rate_limited climbing → quota exhausted. Stop the normal report. Lead with this instead, get the exact numbers from sentry api "/customers/ucar-inc/" (categories.errors: usage / reserved / usageExceeded, plus billingPeriodEnd), and say plainly that the issue list below is stale as of the last accepted event.

1. Scan Issues

Run these in parallel, one per project:

sentry issue list ucar-inc/teamclu-react --query "is:unresolved" --period 48h --json --fields shortId,title,priority,level,status --limit 30
sentry issue list ucar-inc/teamclu-rust  --query "is:unresolved" --period 48h --json --fields shortId,title,priority,level,status --limit 30
sentry issue list ucar-inc/teamclu-ios   --query "is:unresolved" --period 48h --json --fields shortId,title,priority,level,status --limit 30
sentry issue list ucar-inc/teamclu-expo  --query "is:unresolved" --period 48h --json --fields shortId,title,priority,level,status --limit 30

Use --period for the time window (24h / 48h / 14d), not a lastSeen: clause. Default is 90 days, which is far wider than a daily report wants.

Filter results: keep only issues where level is fatal OR priority is high.

--fields gotcha (CLI 0.26.1): count, userCount, firstSeen and lastSeen are listed in --help but are silently dropped from issue list output — you get the key omitted, not an error. Volume and recency have to come from sentry issue view <shortId> --json, which does return them. Do not report event counts sourced from issue list.

If no issues match and step 0 was clean, skip to step 4 with the "全部正常" message. If step 0 was not clean, say so instead — an empty list under an exhausted quota means nothing.

2. Analyze Root Causes (Local)

For each filtered issue (max 10 total), perform local root cause analysis:

1. Fetch issue details with stack trace, which also carries the volume numbers:

sentry issue view <shortId> --json

2. From the stack trace / error message, identify the relevant source files and functions in the codebase.

3. Read those source files to understand the code context around the error site.

4. Produce a one-sentence root cause summary based on the stack trace + source.

Two things worth checking before writing the summary:

• Group splits. The same defect often appears as several issues — a sourcemapped build and a minified one group separately. Compare metadata.value across the filtered set and treat identical values as one root cause rather than reporting the same bug three times.
• Prefer a sourcemapped frame. When several groups share a value, analyze the one whose culprit is a repo path (/src/...) rather than a bundle (assets/index-*.js) — it names the file directly.

When there are more than ~4 issues to analyze, run them as parallel subagents via the Agent tool; each runs sentry issue view, reads the relevant sources, and returns one sentence. For fewer than that, just do it inline — spawning agents costs more than it saves.

If analysis cannot determine a root cause, use the error title as-is and say the root cause is undetermined. Do not guess.

3. Format Report

Sentry 日报 <YYYY-MM-DD>

【Web / 桌面】N 个高优 issue
• <shortId> [<level>] <title> — 根因：<root cause summary>
• ...

【桌面 Rust】N 个高优 issue
• ...

【iOS】N 个高优 issue
• ...

【Expo】N 个高优 issue
• ...

修复命令：/sentry-fix <top-issue-id>

Omit any project section with zero matching issues. When step 0 found the quota exhausted, put that first, above every section:

⚠️ Sentry 配额已耗尽（<usage>/<reserved>），<date> 起事件全部被丢弃，<billingPeriodEnd> 重置。
以下列表停留在最后一条被接收的事件，不代表当前状态。

4. Report Out

Present the report in the conversation.

Pushing to WeCom is a separate step that needs the user's go-ahead, unless this run is the scheduled daily report (/loop 24h /sentry-monitor), where pushing is the whole point. When the user asked for an analysis rather than a daily report, show the report and offer to push — do not push unasked, since it posts to a group chat.

wecom-cli msg send_message '{"chat_type": 2, "chatid": "wrOOClYgAA5gMJijxEUfWC6M0RAjwlWQ", "msgtype": "text", "text": {"content": "<report text>"}}'

If no fatal/high issues exist anywhere and the quota gate was clean:

Sentry 日报 <YYYY-MM-DD> — 全部正常，无高优 issue

Usage

• One-time: /sentry-monitor
• Recurring: /loop 24h /sentry-monitor

Constraints

• This skill is READ-ONLY. Never modify any code files.
• Do not attempt to fix issues. Only report them.
• If sentry CLI is not authenticated, prompt the user to run sentry auth login.
• Never pipe a sentry command through tail/head when you care about success — the pipeline's exit code is the pager's, so a failed call reads as exit 0. Redirect to a file and check $?.