with one click
sentry-health
// Queries Sentry for syncstorage-rs (project syncstorage-prod) to surface error trends, new issues, regressions, and production health signals. Reports as engineer/manager view of what requires attention.
// Queries Sentry for syncstorage-rs (project syncstorage-prod) to surface error trends, new issues, regressions, and production health signals. Reports as engineer/manager view of what requires attention.
Queries, summarizes, creates, and edits Jira issues for syncstorage-rs (project STOR). Supports user-centric work views, epic breakdowns, structured summaries with impact/context/highlights, and ticket creation or modification from natural language.
Runs clippy, cargo audit, and all relevant multi-backend Makefile targets for files changed in the current branch. Detects code smells, anti-patterns specific to this codebase, and surfaces issues across every affected backend before CI catches them. Also handles dependency-update verification (Cargo.toml / Cargo.lock changes from dependabot or manual bumps) via the `deps` mode.
Brings up the Spanner emulator, provisions the test database with the project schema, and runs the syncstorage-rs Spanner unit-test suite locally. Repeatable single-command flow plus full from-scratch documentation. Also covers the e2e (docker-compose) path.
Checks that trait method changes in syncstorage-db or tokenserver-db are consistently implemented across all backend crates (mysql, postgres, spanner). Flags missing impls, behavioral drift, and Spanner-specific assumptions leaking into shared code.
Reviews conftest.py and helpers.py files in tools/integration_tests/ against the repo's fixture/helper separation standard. Flags helpers in conftest, missing teardown, wrong scopes, and raw DB operations outside helper functions.
Reviews new or modified error variants in syncstorage-rs for correct Sentry routing, HTTP status mapping, and response safety. Enforces the is_sentry_event() / maybe_emit_metrics() classification pattern.
| name | sentry-health |
| description | Queries Sentry for syncstorage-rs (project syncstorage-prod) to surface error trends, new issues, regressions, and production health signals. Reports as engineer/manager view of what requires attention. |
| user-invocable | true |
| argument-hint | new | regressions | volume | full (default: full) |
You are acting as both engineer and engineering manager for syncstorage-rs. You are reviewing Sentry to understand production error health, spot regressions, and flag issues that need triage or fixes.
Start by reading .claude/mcp-context.md for project slugs, environments, what to flag, and what is expected noise.
Parse $ARGUMENTS (trimmed, lowercased). Default is full. Valid modes:
new — issues first seen in the last 7 daysregressions — previously resolved issues that have recurredvolume — high-event-count issuesfull — all of the aboveCall mcp__sentry__find_projects and locate the syncstorage-prod project under the mozilla organization. Confirm the project slug and organization slug before querying. If the project is not found, report the available projects and stop.
Use available Sentry MCP tools to fetch issues for syncstorage-prod. Apply environment filter production unless the user has specified otherwise.
Fetch based on the selected mode:
new, full)Issues with firstSeen in the last 7 days that have not been resolved. These are the riskiest — they represent new failure modes introduced recently.
Sort by: event count descending.
For each, capture:
regressions, full)Issues that were previously marked resolved but have reoccurred. These indicate incomplete fixes or flaky patches.
For each, capture:
volume, full)Issues with the most events in the last 24 hours, regardless of age. These are the most actively impacting users.
For each, capture:
For every issue surfaced, classify it against the known patterns in .claude/mcp-context.md:
Tokenserver auth path — involves hawk_identifier, FxA OAuth, tokenserver-auth/, client_state, keys_changed_at. These are user-facing auth failures — high priority.
Database layer — involves DbError, diesel, deadpool, connection pool, migration, query timeout. May indicate infrastructure problems.
Syncstorage storage path — involves BSO read/write, collection operations, quota. Usually lower priority unless volume is very high.
Expected noise — 409 Conflict, 503 during deployment, staging-environment-only errors. Mark as "noise" and exclude from the action list.
Spanner-specific — RST_STREAM, gRPC errors in production (not emulator). These should NOT appear in production — flag immediately.
If recent Jira data is available in this conversation, check whether any Sentry issues correspond to open STOR- bugs. Note the link if found.
If a high-volume or regression Sentry issue has no corresponding Jira ticket, that is a gap — flag it as "needs ticket".
One-line overall assessment.
Table: Issue ID | Title | First Seen | Events | Classification If none: "No new issues in the last 7 days."
Table: Issue ID | Title | Resolved On | Recurred On | Events Since If none: "No regressions detected."
Table: Issue ID | Title | Events (24h) | Triaged? | Classification Exclude known noise (mark separately if many).
Bulleted findings only if genuine patterns are present:
Up to 5 concrete items. Each: issue ID, what to do, urgency. Skip if no action is warranted.
Brief list of issues seen but classified as expected noise. One line each. This confirms you looked at them.
is_sentry_event() in syncserver/src/error.rs is the canonical routing decision — errors that are HTTP 4xx should generally not be in Sentry at high volume; flag if they areSYNCSTORAGE-PROD-####) if available