OpenParable
Skip to content
← Back to skills

Sentry Health

DevOps & Security
sentry-health

Sentry Health is an Agent Skill for devops & security published in the mozilla-services/syncstorage-rs repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.

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.

View on GitHub ↗
QUICK START

How to use this skill

Bring this guide into your coding agent with a prompt tailored to the tool you use.

  1. Open your project in Codex.
  2. Copy and paste the prompt below.
  3. Review files and risks before approving any action.
Prompt to paste
Inspect the Agent Skill at https://github.com/mozilla-services/syncstorage-rs/blob/HEAD/.claude/skills/sentry-health/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/sentry-health, but wait for my approval before writing files or running scripts.

Copying this prompt does not install or run the skill. Review third-party files before use.

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 days
  • regressions — previously resolved issues that have recurred
  • volume — high-event-count issues
  • full — all of the above

Step 1: Confirm the project

Call 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.

Step 2: Gather issue data

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 issues (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:

  • Issue ID and title
  • First seen timestamp
  • Event count in the period
  • Affected users (if available)
  • Platform / culprit (the Rust file/function if available)

Regressions (regressions, full)

Issues that were previously marked resolved but have reoccurred. These indicate incomplete fixes or flaky patches.

For each, capture:

  • Issue ID and title
  • Original resolution date
  • Recurrence date
  • Event count since recurrence

High-volume issues (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:

  • Issue ID and title
  • Event count (24h)
  • Is this a known/triaged issue or unacknowledged?

Step 3: Classify each issue

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.

Step 4: Cross-reference with Jira (if context available)

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".

Step 5: Output format

Production Health: [OK / Watch / Degraded]

One-line overall assessment.

New Issues (Last 7 Days)

Table: Issue ID | Title | First Seen | Events | Classification If none: "No new issues in the last 7 days."

Regressions

Table: Issue ID | Title | Resolved On | Recurred On | Events Since If none: "No regressions detected."

High-Volume Issues (Last 24h)

Table: Issue ID | Title | Events (24h) | Triaged? | Classification Exclude known noise (mark separately if many).

Error Pattern Analysis

Bulleted findings only if genuine patterns are present:

  • Auth path errors (tokenserver risk)
  • DB layer errors (infrastructure risk)
  • Sudden volume spikes (availability risk)
  • Patterns that correlate with a recent deploy or migration

Recommended Actions

Up to 5 concrete items. Each: issue ID, what to do, urgency. Skip if no action is warranted.

Noise / Expected Errors (Acknowledged)

Brief list of issues seen but classified as expected noise. One line each. This confirms you looked at them.

Guidelines

  • Do not fabricate event counts or timestamps — use exactly what Sentry returns
  • If a query fails or a tool is unavailable, note it and work with available data
  • 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 are
  • Focus on production environment; staging errors are informational only
  • An issue being "old" does not mean it's not important — check event count trends, not just age
  • Sentry issue IDs should be referenced in full (e.g. SYNCSTORAGE-PROD-####) if available