home / skills / codyswanngt / lisa / ops-monitor-errors

This skill monitors Sentry for unresolved frontend and backend errors, filtering by project, environment, and time range to help you triage quickly.

npx playbooks add skill codyswanngt/lisa --skill ops-monitor-errors

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.8 KB
---
name: ops-monitor-errors
description: Monitor Sentry for unresolved errors in frontend and backend projects. Supports filtering by project, environment, and time range.
allowed-tools:
  - Bash
  - Read
---

# Ops: Monitor Errors

Monitor Sentry for errors in the application.

**Argument**: `$ARGUMENTS` — project (`frontend`, `backend`, `all`; default: `all`) and optional time range (default: `1h`)

## Discovery

Discover Sentry configuration from:
1. `.sentryclirc` — org and project names
2. `.env.*` files — `EXPO_PUBLIC_SENTRY_DSN` for DSN
3. `package.json` — `@sentry/react-native` (frontend) or `@sentry/node` (backend) for project type

## Sentry CLI

### List Unresolved Issues

```bash
sentry-cli issues list \
  --org {org} \
  --project {project}
```

### Filter by Environment

```bash
sentry-cli issues list \
  --org {org} \
  --project {project} \
  --query "is:unresolved environment:{env}"
```

### Post-Deploy Check (new issues since deploy)

```bash
sentry-cli issues list \
  --org {org} \
  --project {project} \
  --query "is:unresolved firstSeen:-{time}"
```

Where `{time}` is a Sentry duration like `1h`, `30m`, `24h`.

## Sentry API (Fallback)

If `sentry-cli` is not installed or not authenticated, use the API directly:

### List Unresolved Issues

```bash
curl -sf "https://sentry.io/api/0/projects/{org}/{project}/issues/?query=is:unresolved&sort=date" \
  -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" | \
  jq '.[] | {id: .id, title: .title, count: .count, userCount: .userCount, firstSeen: .firstSeen, lastSeen: .lastSeen}'
```

### Filter by Environment

```bash
curl -sf "https://sentry.io/api/0/projects/{org}/{project}/issues/?query=is:unresolved+environment:{env}&sort=date" \
  -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" | \
  jq '.[] | {id: .id, title: .title, count: .count, userCount: .userCount}'
```

## Post-Deploy Workflow

After any deployment:

1. Wait 5 minutes for errors to surface
2. Check for new unresolved issues in the deployed environment
3. Assess severity: are these new regressions or pre-existing?
4. Report findings with severity assessment

## Output Format

Report errors as a table:

| Issue ID | Title | Events | Users | First Seen | Severity |
|----------|-------|--------|-------|------------|----------|
| 12345 | TypeError: Cannot read property 'name' | 42 | 15 | 5m ago | HIGH |
| 12346 | Network request failed | 3 | 2 | 2h ago | MEDIUM |

### Severity Classification

| Severity | Criteria |
|----------|----------|
| CRITICAL | > 100 events or > 50 users in last hour |
| HIGH | > 10 events or > 5 users, appeared after deploy |
| MEDIUM | Recurring issue, < 10 events |
| LOW | < 3 events, no user impact |

Include summary: total unresolved issues, new since last deploy, and recommendation (proceed / investigate / rollback).

Overview

This skill monitors Sentry for unresolved errors across frontend and backend projects, with optional filtering by project, environment, and time range. It discovers Sentry configuration from common locations and uses sentry-cli or the Sentry API to list and filter issues. The skill outputs a concise table, severity classification, and a deployment recommendation.

How this skill works

The skill inspects repository files and environment settings to find Sentry org, project, and DSN, then queries Sentry for unresolved issues. It prefers sentry-cli when available and falls back to the Sentry HTTP API using an auth token. Results are filtered by project (frontend/backend/all), environment, and time range to report new and existing errors.

When to use it

  • After any deployment to validate no new regressions surfaced
  • During triage to get a focused list of unresolved issues by project or environment
  • In CI/CD pipelines as a post-deploy check with a short time window (e.g., 5–60 minutes)
  • When onboarding or auditing a repo to discover Sentry configuration and coverage
  • Regular health checks for weekly error monitoring and incident review

Best practices

  • Wait ~5 minutes after deployment before running the post-deploy check to allow errors to surface
  • Prefer sentry-cli for convenience; ensure SENTRY_AUTH_TOKEN is available when using the API fallback
  • Filter by environment to avoid noisy cross-environment results (production vs staging)
  • Use a short time window (e.g., 1h or 30m) for post-deploy checks and a longer window for ongoing monitoring
  • Classify severity by events and user impact and include a clear recommendation (proceed / investigate / rollback)

Example use cases

  • Post-deploy CI job: run with project=frontend and time range=30m to detect regressions introduced by the latest release
  • Incident investigation: list unresolved issues in production environment for the backend to prioritize fixes
  • Health dashboard: scheduled check that aggregates total unresolved issues and new issues since last deploy
  • Onboarding audit: detect whether Sentry is configured and which package (react-native or node) indicates project type

FAQ

What if sentry-cli is not installed or authenticated?

The skill falls back to the Sentry HTTP API. Provide SENTRY_AUTH_TOKEN in the environment and the skill will query the projects endpoint to list unresolved issues.

How is severity determined?

Severity is classified by event count, unique users, and whether the issue appeared after deploy. Rules: CRITICAL (>100 events or >50 users in last hour), HIGH (>10 events or >5 users after deploy), MEDIUM (recurring, <10 events), LOW (<3 events, no user impact).