You shipped the fix. Read the count.

The ticket closes. The question stays open.

The pull request merges, the deploy goes green and the ticket moves to Done. Nobody can say whether one customer has it easier.

Two weeks later, someone asks in a meeting: "What changed after that fix?" Someone opens a dashboard. Someone else watches five recordings. The answer is a feeling.

You do not need more data. You need one number, counted the same way twice. Release check counts it again after each release that names it. The number tells you what changed. It does not tell you why.

How it works

A finding is a problem that Sequential counts across sessions on one page of your product, for example F-12, a failed request on the shipping page. In plain words, people get stuck at the shipping address. Release check counts it from the events that your SDK already sends: every session with an event on that page, and every session in which the problem occurred. The counts are exact. Sequential counts before and after the release by the same rule.

1. 01

   Record the release.

   Make one call from your deploy, or let your agent make it. Name the findings that the release addresses.

2. 02

   Sequential counts again.

   About once an hour, it counts the sessions before the release and after it.

3. 03

   Read the numbers.

   The finding and your agent get both rates, each with a range. While traffic is too low, the card says how many sessions it needs, for example "(needs 120 to tell)".

The card shows the status in order: Fix released, then Measuring, then the result. Only Worse and Regressed are amber.

One release, start to finish

This example is illustrative. Northlight Outfitters is a fictional shop, and every number here is made up.

Sequential found a failed request on the shipping page. It hit 38 people. A postcode with a space was rejected. The team’s agent filed WEB-231 and drafted a fix. An engineer reviewed the fix and merged it.

The deploy recorded release 2026.10.09 and named the finding. Sequential counts sessions, not people. When enough sessions came, the card showed Improved: "After 2026.10.09, 10 of 82 sessions had it (7–21%); before, 123 of 300 (36–47%)."

Asked how the release went, the agent answered with what Sequential measured: "Since release 2026.10.09: 41% → 12% of sessions on the shipping page hit it."

Not a yes. A number you can act on. 12% is still a problem, and now the team knows it.

Your agent reads the count

Connect Claude Code, Cursor, Codex, Claude Desktop or another MCP client with a project access token. Then ask your agent how a release went. It answers with Sequential’s count, not a guess.

• Mark the deploy, link the work. record_release takes a version and the findings that the release addresses. link_fix attaches the pull request, the commit or the issue.
• Ask, and pass it on. get_verification returns the counts, the ranges and the notes. Your agent can post them in your tracker or chat.

Careful by construction

Before-and-after numbers are easy to get wrong. The card is strict about what it claims.

• Exact counts, honest ranges. Session counts are exact. Each rate shows how far chance alone could move it, for example "4 of 200 sessions (1–5%)".
• Plain results. Confirmed fixed: none of enough sessions after the release had it. Improved: a lower share had it, by more than chance.
• Stale tabs do not count. When your events carry the release name, only sessions on the new release count. A tab that stays open across the deploy counts on neither side.
• Notes, never blame. Another release, a big shift in traffic or low traffic gets a note. A note never changes the result.
• A good result stays watched. For 30 days. If the problem comes back, Confirmed fixed becomes Regressed.

From your deploy: one call

Does your SDK already send events? Then create a token with the preset "For CI: mark a release when you deploy" and add one call to your deploy.

curl -X POST https://api.usesequential.com/api/releases \
  -H "Authorization: Bearer $SEQUENTIAL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"version":"2026.10.09","finding_ids":["F-12"]}'

Only the version is required. Name the findings that you want Sequential to count.

Good to know

• Answers wait for traffic. If 4% of sessions had the problem before, Confirmed fixed needs 150 sessions after with none. Rare problems and quiet pages take longer. The hosted preview keeps 7 days of data by default, so a quiet page can end Not measured. Not measured always gives the reason.
• Small changes can read No change. The card is sized to show the rate halving. A smaller improvement may not show as Improved.
• Send the release name for the cleanest read. Without it, Sequential compares by time, from two hours after the release, and labels the result time-based. Old and new versions then mix. If your SDK already sets an app version, it must match the version that you record exactly.
• A release measures only the findings it names. A linked pull request or a commit message starts nothing by itself.
• The count is only as good as the finding. It counts the problem exactly as the finding defines it.
• Only your own environment is measured. A staging release shows on the card, but Sequential does not count it.
• No command-line tool yet. A command-line tool and a GitHub Action are not published yet. Today you use one API call, or your agent.

Fair questions