How visual testing snapshots are counted and billed

Every build draws on your team's monthly snapshot allowance. The count is per capture, not per story or per build, so modes, browsers, and named captures multiply it, while skip-unchanged and opt-outs bring it down.

A snapshot is one capture that UI Verify renders, or takes as uploaded, and diffs against its baseline when it has one (a first capture becomes the baseline to review). What makes one depends on what you upload.

Playwright and Vitest captures render in one mode in Chrome, and uploaded screenshots are diffed as they are, so each capture is exactly one snapshot.

A Storybook story counts once for every mode and every browser it renders in: snapshots = stories x modes x browsers. A story with no declared modes renders in one default mode, and a project renders in Chrome only unless you turn on Firefox or Safari in the project's Capture & AI settings.

Add a mode or a browser where it catches a real difference. See Modes for declaring them and Reduce visual test snapshots and cost for keeping the story count down.

A snapshot's weight is how much of the allowance it uses. Not every snapshot in a build weighs the same:

Yes, at a fifth of a rendered snapshot. With --only-changed, a story your change cannot affect is not rendered: its baseline is reused as this build's result. The build still covers it, so it counts as 0.2, which is far less than rendering it. That makes `--only-changed` the biggest lever on usage for Storybook and Vitest uploads. Playwright archives and screenshot uploads have no dependency graph, so every capture renders and counts as 1.

No. A story with disableSnapshot: true (under parameters.uiVerify or parameters.chromatic) is never rendered and never counted, and Storybook docs pages are not snapshotted. See Storybook parameters.

No. When a story comes back changed, flake detection renders it a few more times to check the change reproduces. Usage counts the snapshots a build dispatched, not the renders, so a re-rendered story is still one snapshot.

No. A build that fails as a whole, where nothing could render, uses no snapshots, and neither does a build paused at the snapshot limit. A build that finishes as passed or changed counts every snapshot it dispatched, including a story that failed to render inside it.

A Storybook with 200 stories, 2 modes each, rendered in Chrome only, is 400 snapshots for a full build. With --only-changed, a pull request that affects 30 of those stories renders their 60 snapshots and carries the other 340 forward.

Without --only-changed the same build counts 400. At 128 per build, the Free allowance of 10,000 snapshots a month covers about 78 such builds, and the open-source allowance of 50,000 for public repos covers about 390.

The snapshot allowance is how many snapshots a team can use in a billing period, shared across all of the team's projects. Free teams get 10,000 snapshots a month and open-source teams (public repos) get 50,000 a month; see Free for open source for the larger one.

Paid plans include a larger monthly allowance and bill snapshots past it as overage instead of pausing builds. See pricing for plans and rates, and the pricing calculator to estimate a month from your story count. AI reviews by the AI judge are counted separately and never pause a build.

On the Free and open-source plans, the allowance resets at the start of each calendar month, at 00:00 UTC on the 1st. Unused snapshots do not roll over. On a paid plan, the period follows your subscription's billing cycle.

On the Free and open-source plans, a build that would take the team past its allowance is paused before it renders. It is marked Blocked, none of its snapshots render, and it uses nothing. The check is per build, so a build that does not fit in what is left of the allowance is blocked whole, not partly rendered.

• CI: uiverify upload logs that the build is blocked and exits 1, even with --exit-zero-on-changes or --no-strict.
• Pull request: with the GitHub App connected, the UI Verify commit status ends in an error state reading "Build paused: screenshot allowance exceeded", linking to a page to get in touch about a higher limit.
• Dashboard: the build shows a red Blocked badge.

A blocked build does not resume on its own. Once the allowance resets or your limit is raised, push again or re-run the CI job.

The team's Usage page, under the team's settings, shows snapshots used this billing period against your plan allowance, plus builds and snapshots per project over the last 7 or 30 days. It counts with the same weights as this page, so the number there is the number that counts against your allowance.