When alerts accumulate, establish which errors are still happening before changing code. This Skill lets Codex inspect Sentry issues and events, then organize counts, recent occurrences and associated releases for a handoff or investigation. Its scope is read-only observation. Query results and AI explanations still need validation against the project.
Install and prepare
This guide covers the standalone Skill retained in openai/skills. That repository is deprecated and current examples have moved to openai/plugins; the instructions here describe the linked standalone version, not the latest plugin.
Enter this line in the Codex conversation, not a terminal. If the installed Skill does not appear, restart Codex.
$skill-installer sentry
- A Sentry account with access to the intended organization and project
- The sentry CLI described at cli.sentry.dev, rather than the older sentry-cli command
- The intended project, exact environment name and explicit time window
Prepare the CLI using Sentry’s website, then run sentry auth login in a terminal and verify with sentry auth status. Keep tokens in local configuration, outside the conversation. The CLI can detect a project from configuration, but check the detected target before the first query. [4]
Try a first task
Fill in the project and exact environment, then inspect the past day:
$sentry
Read unresolved Sentry issues for [organization]/[project] over the last 24 hours, using environment [exact value from Sentry]. Return at most 10, ordered by most recently seen. Confirm the target and filters first. Include title, short ID, count, last seen and available links. Inspect events and releases for the two most useful issues to investigate. Mark missing fields. Do not change issue status or code. Redact emails and IP addresses; omit raw stack traces.
Work through the task
-
Set the scope. Specify organization, project, period and environment. production and prod are different strings: use the actual recorded value and override incorrect automatic project detection.
-
Move from list to events. Request an issue overview with JSON for processing. Select a short ID such as ABC-123, then inspect its details and recent events. Do not substitute an internal numeric ID.
-
Separate evidence from inference. Explain priorities using occurrence times, counts, releases and environments. Treat generated explanations or repair plans as hypotheses supported by specific events, then define the code investigation needed to check them.
Move from an alert to an inspectable event
Start with one question: “In the last 24 hours, are payment-webhook errors in production concentrated in one release?” Name the organization and project; if the CLI detects the wrong project, supply org/project explicitly. Read the Issue list with --json, then inspect one short issue ID and its events. The short ID differs from Sentry’s internal numeric ID; copying the wrong one can make a lookup fail.
An Issue aggregates multiple events. Compare occurrence time, release, environment and a few individual event details before linking it to a deploy. prod and production are distinct environment strings; filtering the wrong one can hide the real issue. For access failures, inspect local authentication and permissions rather than asking someone to paste a full token into chat.
Separate observation from explanation
A useful output states the filters, number or sample of events seen, relevant stack frames, affected release and next code path to inspect. A CLI or AI root-cause suggestion is only a candidate explanation. If the event data lacks context, say that the cause cannot yet be confirmed. This Skill performs read-only observation; viewing an Issue does not repair or resolve it.
Check the result
Expect a scoped issue list and concise event summaries for selected items. Spot-check identifiers and links against the intended project. Counts and dates must come from returned data. An empty result means no matches within those filters, not proof of overall system health.
Common blockers
Expected errors are missing. Check the project, time window, unresolved filter and exact environment spelling. Widen one condition at a time.
The command or authentication fails. Verify the newer sentry CLI, authentication status and project access. Do not paste a token into chat.
Counts or releases are absent. Inspect relevant detail or event data; label unavailable fields instead of guessing.
An explanation sounds conclusive. Ask for supporting events, code locations and unverified assumptions. Reading telemetry alone does not validate a fix.
Group recurring errors before fixing them
For a recurring error, do not inspect only the newest event. Use this read-only skill to collect related issues over a defined period, group events by suspected cause, and compare one group with code and release history. Claire Vo described a broader Codex workflow that classified historical Sentry editing errors and worked through them by category; she did not identify this standalone skill. Here, finish with a clear evidence summary, then handle code changes and validation as a separate task.