What it does
Right after a release, the crash-free rate swings with every few hundred sessions, and it is easy to celebrate or panic too early. App stores, product leads and the on-call engineer all watch the same number, usually by refreshing the Releases page.
The agent finds the newest release, reads its crash-free session rate from Sentry's release health data, puts it next to the previous release, and says what share of traffic is on the new version yet. A 99.1% on 3% of sessions is labelled early, not alarming, and the crashes behind the number are listed by users affected.
How it works
1Find the latest release
GET /api/0/organizations/{org}/releases/?project=<id>&per_page=2returns the newest releases first. Keep the version anddateCreatedof the latest and of the one before it.2Read crash-free rates
GET /api/0/organizations/{org}/sessions/?project=<id>&field=crash_free_rate(session)&field=crash_free_rate(user)&field=sum(session)&query=release:<version>&statsPeriod=24h&interval=4h, once for each release, over the same window.3Work out adoption
Divide the new release's
sum(session)by all sessions in the project over the same window (the same call without the release filter). Under 10% adoption or 1,000 sessions, call the rate early.4Find the crashes behind it
List the release's top crash issues with
GET .../issues/?query=release:<version> error.unhandled:true&sort=user&limit=5.- 5
5Judge
Healthy when the rate is within 0.3 points of the previous release, regressed when it is lower by more than that with at least 1,000 sessions, early when there is too little traffic to tell.
Post it to the board
With
BRIEFKIN_TOKENset, the agent sends the result as one card that updates in place every run. Without it, you get the report in the chat.
What you get
- Crash-free sessions for the latest release, and for the previous one over the same window.
- Crash-free users alongside.
- Adoption: the share of sessions on the new release, and the session count behind the rate.
- Top crashes in the release, by users affected.
- A verdict: healthy, early or regressed.
Install and run it
Pick your agent, where the data comes from and how to schedule it; the commands below follow.
Install the skill
One command. It puts the SKILL.md in ~/.claude/skills and in ~/.agents/skills, which Codex, Cursor, Gemini CLI, Copilot CLI and OpenCode read too.
shell
curl -fsSL https://briefkin.dev/skills/sentry-crash-free-sessions/install | shRun it
Ask Claude Code:
prompt
Run the sentry-crash-free-sessions skillOr paste the prompt instead of installing:
prompt
Using the Sentry API (or the Sentry MCP server), find the two newest releases of project acme-ios (GET /api/0/organizations/{org}/releases/). From the sessions endpoint (GET /api/0/organizations/{org}/sessions/ with field=crash_free_rate(session), crash_free_rate(user) and sum(session)), give me the crash-free session and user rates for each release over the same window, and the new release's share of all sessions. List its top 5 crash issues (release:<version> error.unhandled:true, sorted by users). Call the result healthy (within 0.3 points of the previous release), regressed (lower by more, with 1,000+ sessions) or early (under 10% adoption or 1,000 sessions).Put it on a schedule
Every 4 hours, from cron on any machine where Claude Code is signed in:
crontab
0 */4 * * * claude -p "Run the sentry-crash-free-sessions skill"Add it with
crontab -e. A laptop asleep at that time runs it when it wakes if you use launchd or Task Scheduler instead; GitHub Actions works for the API route.Send it to your board
Connect Briefkin once with
curl -fsSL https://briefkin.dev/install | shand every run lands on your board as a stat tile. How setup works
View the SKILL.mdRaw file
SKILL.md---
name: sentry-crash-free-sessions
description: "Every 4 hours: the crash-free session rate of your newest release next to the previous one, with adoption, so an early number is read with care. Use when the user asks for this, or when it runs on a schedule."
---
# Sentry crash-free sessions for the latest release
Every 4 hours: the crash-free session rate of your newest release next to the previous one, with adoption, so an early number is read with care.
Right after a release, the crash-free rate swings with every few hundred sessions, and it is easy to celebrate or panic too early. App stores, product leads and the on-call engineer all watch the same number, usually by refreshing the Releases page.
The agent finds the newest release, reads its crash-free session rate from Sentry's release health data, puts it next to the previous release, and says what share of traffic is on the new version yet. A 99.1% on 3% of sessions is labelled early, not alarming, and the crashes behind the number are listed by users affected.
## Two ways to get the data
Use the API or MCP route when you have an MCP server, a CLI or an API token for the app. Otherwise, if you can drive a browser the user is signed in to (Claude in Chrome, a Playwright or Chrome DevTools MCP server), use the browser route. Say which one you used.
## Route A: API or MCP server
### What you need
- Release health on: the SDK sets `release` and sends sessions (the mobile SDKs and recent JavaScript SDKs do by default).
- A Sentry token with `org:read`, `project:read` and `event:read` in `SENTRY_AUTH_TOKEN`, or the Sentry MCP server.
If something is missing, say what and stop; do not invent numbers.
### Steps
1. **Find the latest release** (Sentry): `GET /api/0/organizations/{org}/releases/?project=<id>&per_page=2` returns the newest releases first. Keep the version and `dateCreated` of the latest and of the one before it.
2. **Read crash-free rates** (Sentry): `GET /api/0/organizations/{org}/sessions/?project=<id>&field=crash_free_rate(session)&field=crash_free_rate(user)&field=sum(session)&query=release:<version>&statsPeriod=24h&interval=4h`, once for each release, over the same window.
3. **Work out adoption** (Sentry): Divide the new release's `sum(session)` by all sessions in the project over the same window (the same call without the release filter). Under 10% adoption or 1,000 sessions, call the rate early.
4. **Find the crashes behind it** (Sentry): List the release's top crash issues with `GET .../issues/?query=release:<version> error.unhandled:true&sort=user&limit=5`.
5. **Judge**: Healthy when the rate is within 0.3 points of the previous release, regressed when it is lower by more than that with at least 1,000 sessions, early when there is too little traffic to tell.
## Route B: the browser
### What you need
- Signed in to Sentry as a member of the organization that owns the project; the Releases page shows health only for projects whose SDK sends sessions.
If something is missing, say what and stop; do not invent numbers.
### Steps
Start at https://sentry.io/releases/. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears.
1. **Open Releases for the project**: The URL opens the Releases page of your last organization; switch organizations in the top left if needed. Pick the project (acme-ios) in the project selector, set the time range to **24H**, and set **Display** to `Sessions`.
2. **Read the two newest releases**: With the list sorted by date created, the top two rows are the latest release and the one before it. For each, note the version, **Crash Free Rate**, **Adoption** and the session count in the row.
3. **Open the latest release**: Click its version. On the release page read **Crash Free Session Rate**, **Crash Free User Rate** and **Session Count** from the table under the chart, and the **Sessions Adopted** graph for the share of traffic on it.
4. **List the crashes behind it**: In the **Issues** section of the release page, pick the **Unhandled** tab, then click **Open in Issues** and set Sort to `Users` to get the top five crashes by users affected.
5. **Judge**: Healthy when the new rate is within 0.3 points of the previous release, regressed when it is lower by more than that with at least 1,000 sessions, early when adoption is under 10% or under 1,000 sessions.
Note: The Releases list rounds crash-free rates to two decimals and the release page time range defaults to the whole life of the release, so set 24H on both to compare like with like. Projects without session data show no health columns at all.
## The report
- **Crash-free sessions** for the latest release, and for the previous one over the same window.
- **Crash-free users** alongside.
- **Adoption**: the share of sessions on the new release, and the session count behind the rate.
- **Top crashes** in the release, by users affected.
- A verdict: healthy, early or regressed.
## Post it to Briefkin
When `BRIEFKIN_TOKEN` is set, or `~/.config/briefkin/env` exists (the installer from https://briefkin.dev/docs writes it), also send the result to the user's Briefkin board as one card. Keep the `item_key` the same on every run so the card updates in place, use a new `event_id` per run, and put today's real numbers in place of the example ones. If the request fails, say so once and carry on.
```bash
[ -n "${BRIEFKIN_TOKEN:-}" ] || . ~/.config/briefkin/env
curl -sS -X POST "${BRIEFKIN_URL:-https://briefkin.dev}/v1/events" \
-H "authorization: Bearer $BRIEFKIN_TOKEN" \
-H "content-type: application/json" \
-d @- <<'JSON'
{
"v": 1,
"event_id": "sentry-crash-free-sessions/<date of this run, e.g. 2026-10-16>",
"item_key": "sentry-crash-free-sessions",
"project": "acme-ios",
"source": "Sentry crash-free sessions for the latest release skill",
"kind": "metric",
"title": "Release 4.12.0 is 99.62% crash-free",
"metric": {
"label": "Crash-free sessions",
"value": 99.62,
"unit": "%",
"better": "higher",
"period_start": "<start of the period, ISO 8601>",
"period_end": "<end of the period, ISO 8601>"
},
"glance": [
{
"type": "Grid",
"props": {
"columns": 3
},
"children": [
{
"type": "Stat",
"props": {
"label": "Previous (4.11.2)",
"value": 99.71,
"unit": "%"
}
},
{
"type": "Stat",
"props": {
"label": "Crash-free users",
"value": 99.8,
"unit": "%"
}
},
{
"type": "Stat",
"props": {
"label": "Adoption",
"value": 38,
"unit": "%"
}
}
]
}
],
"widget": [
{
"type": "Table",
"props": {
"columns": [
"Top crash in 4.12.0",
"Users",
"Events"
],
"align": [
"left",
"right",
"right"
],
"rows": [
[
"EXC_BAD_ACCESS in ImageCache.prefetch",
61,
74
],
[
"NSInvalidArgumentException in CheckoutViewController",
23,
25
],
[
"SIGABRT in AVCaptureSession startRunning",
9,
11
]
]
}
},
{
"type": "KeyValue",
"props": {
"items": [
{
"key": "Sessions on 4.12.0",
"value": "48,210"
},
{
"key": "Crashed sessions",
"value": "183"
}
]
}
},
{
"type": "Callout",
"props": {
"text": "0.09 points below 4.11.2, inside the 0.3-point margin. ImageCache.prefetch is behind 74 of the 183 crashes.",
"tone": "info"
}
}
],
"size": "md"
}
JSON
```
Widgets come from the Briefkin catalog (https://briefkin.dev/v1/catalog). Without a token, just give the user the report.
Set `period_start` and `period_end` to the window the number covers: the tile names it from them ("Last 7 days", "Today", "This month"). For a count right now (open items, a balance), send `"period_label": ""` so no period shows; for another name, send it as `period_label` (at most 24 characters).
## Run it on a schedule
Suggested: Every 4 hours (`0 */4 * * *`). From cron, with the agent signed in on that machine:
```bash
0 */4 * * * claude -p "Run the sentry-crash-free-sessions skill"
# Codex: codex exec, Gemini CLI: gemini -p, Copilot CLI: copilot -p, OpenCode: opencode run
```
Or use the agent's own scheduler (Claude Code routines, Codex automations, Claude or ChatGPT scheduled tasks): https://briefkin.dev/skills/sentry-crash-free-sessions#schedule
Source: https://briefkin.dev/skills/sentry-crash-free-sessions
What your agent needs
Release health on: the SDK sets
releaseand sends sessions (the mobile SDKs and recent JavaScript SDKs do by default).A Sentry token with
org:read,project:readandevent:readinSENTRY_AUTH_TOKEN, or the Sentry MCP server.
Connecting Sentry
- Sentry MCP server, Sentry's official remote server at
https://mcp.sentry.dev/mcp, signed in with OAuth. Add Sentry from Claude's connector directory, or runclaude mcp add --transport http sentry https://mcp.sentry.dev/mcp. It searches issues and events and pulls stack traces. sentry-cli. Mostly a release and source map tool, butsentry-cli issues list --project <slug>lists issues when a quick terminal check is enough.- API with an auth token. Create an organization or personal token, store it in
SENTRY_AUTH_TOKENwithSENTRY_ORG, and grantorg:read,project:readandevent:read.
Those three read scopes cover every report here; leave out event:write, which lets a token resolve and assign issues.
Questions
What counts as a crash?
A crashed session is one that ended in an unhandled error, such as an app termination on mobile. Errors you catch and send with captureException mark a session as errored instead, so they do not lower this rate.
The rate is 100% in the first hour. Is that real?
Usually it is too few sessions to mean anything. The skill shows the session count next to the rate and calls anything under 1,000 sessions or 10% adoption early, so a perfect first hour is not read as a perfect release.
Do I need Briefkin to use the Sentry crash-free sessions for the latest release skill?
No. The skill runs with your own agent and gives you the report in the chat. With a Briefkin token set, each run also posts it to your board as a stat tile, so you can glance at it instead of asking again.
Which agents can run it?
Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI, OpenCode, Windsurf and Amp all read SKILL.md files. The install command puts it in ~/.claude/skills and ~/.agents/skills, where they look. ChatGPT, the Claude app and Grok take the prompt instead. Pick your agent under "Install and run it" and the commands change to match.
Can it work without an API or MCP server, from my browser?
Yes. Switch the data source to "Your browser" and the steps change to the Sentry pages themselves: the agent opens sentry.io/releases in a browser you are signed in to and reads the numbers off the page. Claude Code, Codex, Cursor, Claude app and ChatGPT can drive a browser out of the box; Gemini CLI, Copilot CLI and OpenCode need a Playwright or Chrome DevTools MCP server first. It is slower than the API and needs you signed in, so it suits a report you run by hand or from a scheduler on your own computer.