Use Sentry CLI to inspect issues and production error logs.
Install
mkdir -p .claude/skills/sentry && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/600" && unzip -o skill.zip -d .claude/skills/sentry && rm skill.zipInstalls to .claude/skills/sentry
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Use when the user asks to inspect Sentry issues or events, summarize recent production errors, or pull basic Sentry health data via the Sentry CLI; perform read-only queries using the `sentry` command.Key capabilities
- →List Sentry issues
- →View Sentry issue details
- →Inspect Sentry issue events
- →Perform AI-powered root cause analysis for issues
- →Generate AI-powered fix plans for issues
How it works
The skill uses the Sentry CLI to perform read-only queries against Sentry, retrieving issue and event data. It handles authentication and project detection automatically.
Inputs & outputs
When to use sentry
- →List unresolved production errors
- →Summarize recent issues
- →Check system health via Sentry data
About this skill
Sentry (Read-only Observability)
Quick start
- If not already authenticated, ask the user to run
sentry auth loginor setSENTRY_AUTH_TOKENas an env var. - The CLI auto-detects org/project from DSNs in
.envfiles, source code, config defaults, and directory names. Only specify<org>/<project>if auto-detection fails or picks the wrong target. - Defaults: time range
24h, environmentproduction, limit 20. - Always use
--jsonwhen processing output programmatically. Use--json --fieldsto select specific fields and reduce output size. - Use
sentry schema <resource>to discover API endpoints quickly.
If the CLI is not installed, give the user these steps:
- Install the Sentry CLI:
curl https://cli.sentry.dev/install -fsS | bash - Authenticate:
sentry auth login - Confirm authentication:
sentry auth status
- Never ask the user to paste the full token in chat. Ask them to set it locally and confirm when ready.
Core tasks (use Sentry CLI)
Use the sentry CLI for all queries. It handles authentication, org/project detection, pagination, and retries automatically. Use --json for machine-readable output.
1) List issues (ordered by most recent)
sentry issue list \
--query "is:unresolved environment:production" \
--period 24h \
--limit 20 \
--json --fields shortId,title,priority,level,status
If auto-detection doesn't resolve org/project, pass them explicitly:
sentry issue list {your-org}/{your-project} \
--query "is:unresolved environment:production" \
--period 24h \
--limit 20 \
--json
2) Resolve an issue short ID to issue detail
sentry issue view {ABC-123} --json
Use the short ID format (e.g., ABC-123), not the numeric ID.
3) Issue detail
sentry issue view {ABC-123}
4) Issue events
sentry issue events {ABC-123} --limit 20 --json
5) Event detail
sentry event view {your-org}/{your-project}/{event_id} --json
6) AI-powered root cause analysis
sentry issue explain {ABC-123}
7) AI-powered fix plan
sentry issue plan {ABC-123}
Fallback: arbitrary API access
For endpoints not covered by dedicated CLI commands, use sentry api:
sentry api /api/0/organizations/{your-org}/ --method GET
Use sentry schema to discover available API endpoints:
sentry schema issues
Inputs and defaults
org_slug,project_slug: auto-detected by the CLI from DSNs, env vars, and directory names. Override with positional{your-org}/{your-project}if auto-detection fails.time_range: default24h(pass as--period 24h).environment: defaultprod(pass as part of--query, e.g.,environment:production).limit: default 20 (pass as--limit).search_query: optional--queryparameter, uses Sentry search syntax (e.g.,is:unresolved,assigned:me).issue_short_id: use directly withsentry issue view.
Output formatting rules
- Issue list: show title, short_id, status, first_seen, last_seen, count, environments, top_tags; order by most recent.
- Event detail: include culprit, timestamp, environment, release, url.
- If no results, state explicitly.
- Redact PII in output (emails, IPs). Do not print raw stack traces.
- Never echo auth tokens.
Golden test inputs
- Org:
{your-org} - Project:
{your-project} - Issue short ID:
{ABC-123}
Example prompt: "List the top 10 open issues for prod in the last 24h." Expected: ordered list with titles, short IDs, counts, last seen.
When not to use it
- →When modifying Sentry data
- →When full stack traces are required in output
- →When PII should not be redacted
Prerequisites
Limitations
- →Read-only queries only
- →Output redacts PII
- →Does not print raw stack traces
How it compares
This skill provides a structured command-line interface for Sentry data retrieval and analysis, offering a more direct and automatable approach than navigating the Sentry UI.
Compared to similar skills
sentry side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| sentry (this skill) | 10 | 4mo | Caution | Beginner |
| analyzing-logs | 14 | 26d | Review | Beginner |
| obsidian-incident-runbook | 3 | 26d | Review | Intermediate |
| obsidian-observability | 5 | 26d | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by openai
View all by openai →You might also like
analyzing-logs
jeremylongshore
Analyze application logs to detect performance issues, identify error patterns, and improve stability by extracting key insights.
obsidian-incident-runbook
jeremylongshore
Troubleshoot Obsidian plugin failures with systematic incident response. Use when plugins crash, data is corrupted, or users report critical issues with your Obsidian plugin. Trigger with phrases like "obsidian crash", "obsidian plugin broken", "obsidian incident", "debug obsidian failure", "obsidian emergency".
obsidian-observability
jeremylongshore
Set up comprehensive logging and monitoring for Obsidian plugins. Use when implementing debug logging, tracking plugin performance, or setting up error reporting for your Obsidian plugin. Trigger with phrases like "obsidian logging", "obsidian monitoring", "obsidian debug", "track obsidian plugin".
langsmith-observability
davila7
LLM observability platform for tracing, evaluation, and monitoring. Use when debugging LLM applications, evaluating model outputs against datasets, monitoring production systems, or building systematic testing pipelines for AI applications.
network-info
UKGovernmentBEIS
Gather network configuration and connectivity information including interfaces, routes, and DNS
logging-observability
getsentry
Review code for correct logging and error handling patterns. Use when reviewing code that handles errors, uses logging functions, or captures exceptions. Enforces the error hierarchy where 4xx errors are never logged to Sentry and 5xx errors always are. Trigger phrases include "review logging", "check error handling", "audit observability", or verify correct use of logIssue vs logError.