How to Reduce Chromatic Snapshot Usage on a Student Project

Start by measuring usage across the Chromatic account, then enable TurboSnap if the project meets its requirements. Review redundant CI runs and test dimensions, and exclude only stories the team has decided not to cover. These steps can reduce billed snapshots while keeping useful visual regression checks. The savings depend on the project’s build frequency, changed files, test matrix, and configuration; there is no reliable universal percentage.

Chromatic’s published free plan includes 5,000 snapshots per month. Usage is aggregated across projects in an account. After the allowance is exhausted, testing and review pause until the allowance resets or the account upgrades. Public documentation does not establish a separate student quota, so check the account’s billing page or ask Chromatic support about any account-specific eligibility. Chromatic billing · Free plan FAQ

1. Find what is consuming snapshots

Before changing configuration, establish a baseline. In Chromatic’s Billing page, review the current usage for the billing period and open Trends. Since the allowance applies across an account, check each project’s contribution rather than assuming the student project is the only source.

The usage report and Trends can help distinguish a rise in build volume from a rise in snapshots per build. Review the captured-versus-TurboSnap mix, browser and accessibility usage, and changes over time. Export build-level details if you need to identify which CI runs or projects are contributing most. Chromatic usage reports · Understand and optimize snapshot usage with Trends

Record the billing-period snapshot total and remaining allowance.
Compare build count and billed snapshots per build over the same period.
Break usage down by project, visual versus accessibility snapshots, and TurboSnap behavior.
Look for recent changes: a new branch trigger, added browser or mode, more stories, or a CI workflow running twice.

Interaction tests do not incur billed snapshots according to Chromatic’s billing documentation, while visual and accessibility tests do. If the bill rose, check whether the increase came from snapshot-producing test types before changing interaction coverage.

2. Enable TurboSnap when the project is ready

TurboSnap is Chromatic’s main mechanism for reducing snapshots on eligible builds. It uses Git changes and a Webpack or Vite dependency graph to identify stories affected by a change. A captured snapshot costs one billed snapshot; an unaffected snapshot copied from the baseline costs 0.2; a qualifying bypass can cost zero. Actual savings depend on the changes and correct dependency information. Introduction to TurboSnap

Chromatic says TurboSnap unlocks after ten successful CI builds. Its documented setup includes Chromatic CLI 10.0 or later, Storybook 6.5 or later or Vitest 4 or later, Git 2.28.0 or later, a Webpack- or Vite-based setup, correctly configured stories, and UI Tests enabled. Confirm current compatibility and specialized setup instructions in Chromatic’s documentation before relying on the optimization. Setup TurboSnap

Chromatic CLI

Add the documented --only-changed flag to the Chromatic command in the CI step that publishes the Storybook:

npx chromatic --project-token=$CHROMATIC_PROJECT_TOKEN --only-changed

Store the project token as a CI secret. Keep the rest of the project’s existing build and authentication configuration.

GitHub Action

If the project uses Chromatic’s GitHub Action, set onlyChanged: true:

- name: Publish Storybook
  uses: chromaui/action@latest
  with:
    projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
    onlyChanged: true

Use the action version pinned by the project rather than changing versions solely to enable this option. Check the current action documentation for its supported inputs.

Validate the dependency map

TurboSnap’s value depends on knowing which files affect which stories. Review its reported changed stories and bail reasons on representative builds. Pay particular attention to monorepo paths, prebuilt Storybooks, static directories, and files that affect rendering but are outside the usual module dependency graph. Configure those paths according to the setup documentation. A missing dependency can make change detection unreliable; do not treat a lower snapshot count as proof that the right stories were retested.

3. Reduce redundant CI runs without losing important review

Build volume is one driver of snapshot usage. Inspect whether Chromatic runs on every branch push, pull request update, and merge, and whether overlapping workflow triggers cause the same commit to run more than once. Consolidate triggers only when the removed run does not provide review the team needs.

Compare configured browser and mode combinations with the project’s actual requirements. Each dimension can increase work and usage; removing one reduces coverage for that browser or mode. Keep combinations that protect important user-facing behavior and document why any others were removed. The billing docs describe the usage dimensions, but they do not provide a guaranteed savings estimate for an individual project. Billing and usage

A build skipped with Chromatic’s --skip option has zero snapshot charges because the build is skipped. That also means no Chromatic run or review for that event. Use it only for events the team intentionally does not need to review.

4. Exclude snapshots only when the coverage tradeoff is intentional

Story filters and the disableSnapshot parameter can prevent snapshot capture for stories intentionally excluded from visual testing. Use them for stories that are genuinely outside the project’s visual coverage goals, and keep important states and components covered.

// In a Storybook story’s parameters, disable snapshot capture for this story only:
export const DataFixture = {
  parameters: {
    chromatic: { disableSnapshot: true },
  },
};

Chromatic’s ignore mechanisms solve a different problem. .chromatic-ignore, data-chromatic="ignore", and ignoreSelectors hide regions from visual comparison, but still generate billed snapshots. If the goal is to reduce billed snapshot count, ignoring a region will not do that. See Disable snapshots.

Choice	Usage effect	Coverage tradeoff
TurboSnap captures an affected story	1 billed snapshot	Retests the affected story
TurboSnap copies an unaffected snapshot	0.2 billed snapshot	Reuses the baseline for a story judged unaffected
Qualifying TurboSnap bypass	0 billed snapshots	No snapshots for that qualifying build
Exclude a story with a filter or `disableSnapshot`	Avoids that story’s snapshot capture	That story no longer receives the excluded visual check
Ignore a visual region	Does not avoid the billed snapshot	Region is omitted from comparison
Skip the build	0 snapshot charges for the skipped run	No Chromatic run or review for that event

5. Make changes in a safe order

Save the current usage report and note the period’s build count and billed snapshots.
Remove duplicate CI triggers only after confirming which review events are redundant.
Enable TurboSnap when its build threshold and tooling prerequisites are met.
Inspect several builds, changed-story lists, and bail reasons; validate monorepo and static asset paths.
Review browser and mode combinations with the team, preserving the combinations that matter.
Exclude stories only with an explicit coverage decision. Do not use ignore selectors as a billing optimization.
Compare usage in the next billing period and keep the changes whose coverage and usage effects are understood.

6. Budget for the free-plan cap

Chromatic currently documents 5,000 included free snapshots per month. Once the allowance is used, testing and review pause until the next month, when functionality resumes, or an upgrade restores service sooner. Since usage aggregates across projects, check whether other projects share the account. Published material found for this guide does not confirm a student-specific plan or quota; verify any special eligibility in the account or with Chromatic support. These are current published terms and may change. Chromatic free plan FAQ

Common problems and fixes

--only-changed has no effect: TurboSnap may not yet be unlocked, the CLI or framework may not meet the documented prerequisites, or the action input may be missing. Confirm ten successful CI builds, versions, UI Tests, and the correct CLI flag or action input.
Too many stories are recaptured: inspect the changed files and TurboSnap bail reasons. Broad shared dependencies, static assets, or incomplete path configuration can cause broad recapture. Follow the setup guide for the project type and paths.
Concern that a UI change was not captured: validate that the changed file is in the story’s dependency graph and that monorepo or static-directory paths are mapped. Review the build output before trusting the reduced set.
Usage did not fall after adding ignore selectors: ignored regions still produce billed snapshots. Exclude a story only if the team accepts losing its visual snapshot.
The allowance is exhausted despite this project’s low usage: inspect account-level usage and other projects; the allowance is shared across them.
There is no review for an event: check for workflow conditions or --skip. A skipped run saves snapshots by not running Chromatic, so restore the trigger if that event needs review.
Usage changes unpredictably: compare builds, snapshots per build, browser and accessibility counts, and TurboSnap’s captured/copied/bypassed mix in Trends and the usage report.

Performance, reliability, and cost considerations

TurboSnap reduces unnecessary recaptures by reusing snapshots for stories it judges unaffected. It adds reliance on Git history, supported bundlers, and accurate dependency and path mapping. Treat the change list and bail reasons as operational signals, especially after changing build tooling or repository layout.

Reducing CI triggers and test matrix dimensions can lower work and snapshot charges, but also reduces how many changes, browsers, and modes receive review. Story exclusions remove specific visual checks. Choose the smallest reduction that fits the project’s risk and review process, then recheck account-level usage rather than assuming a particular percentage saved.

Or skip the browser setup

If the project also needs screenshots outside Chromatic’s review workflow, ScreenshotNeo is a website screenshot API and MCP server. A single request captures a URL as PNG, JPEG, WebP, or PDF; it does not replace Chromatic’s component visual regression review.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo API documentation for options and formats. Cookie banners are accepted and removed before the shot, along with 60+ known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. Its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

FAQ

Does TurboSnap guarantee a particular savings percentage?

No. The billed amount depends on which stories changed, copied snapshots, qualifying bypasses, and the project’s build and test setup.

Can a student project get a larger free allowance?

The public documentation cited here establishes the ordinary free allowance, not a student-specific quota. Check account billing or ask Chromatic support about eligibility.

Do interaction tests use the snapshot allowance?

Chromatic’s billing documentation says interaction tests do not incur billed snapshots. Visual and accessibility snapshots do.

Does hiding a flaky element lower snapshot usage?

No. Ignoring a region changes comparison behavior, while the snapshot is still billed. Use a story exclusion only when removing that visual check is acceptable.