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-errorsReview the files below or copy the command above to add this skill to your agents.
---
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).
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.
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.
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).