Review workflow

Every Snapvisor build diffs against an approved baseline and waits for a human (or an AI agent over MCP) to approve or reject the changes. This page covers the concepts that shape that workflow.

Baselines and approvals

When a change is detected, the pull request gets a status check linking to a side-by-side review. Approving a change promotes it to the new baseline for that branch — intended changes never nag you twice. Rejecting keeps the previous baseline and fails the check.

Monitoring mode

Not every branch needs a human to approve each change. In the default CI mode, a build compares against the approved baseline on your base branch and waits for review. In monitoring mode, a build with no prior approval doesn't block — it reports a success check and, once approved, becomes the baseline future builds compare against.

Monitoring mode is configured with an auto-approved branches glob pattern in project settings. Any branch matching the pattern is automatically approved and gets a success status check. By default only your default base branch is auto-approved.

main
{main,production}
release/**

Use it for:

• Production or release branches where the merged state is the source of truth, not something to re-review.
• Continuously monitoring a live app for unexpected visual drift rather than gating pull requests.

Flaky test detection

Some screenshots wobble for reasons that aren't real regressions — an animation frame, a timestamp, a random avatar.

• Ignore changes manually — turn on ignore changes in a project's settings and reviewers can mark a recurring change as ignored. Ignored changes no longer require review on future builds.
• Auto-ignore — with ignore enabled, Snapvisor can auto-ignore changes that keep reappearing. A change is treated as flaky once it shows up at least a configured number of times across auto-approved builds within a rolling 7-day window. The default threshold is 3 occurrences; raise it to be stricter, lower it to catch noise sooner.

Auto-ignore is scoped to auto-approved builds, so it learns from branches you already trust rather than from unreviewed pull requests.

Summary checks

A project can produce several builds on the same commit — different apps, shards, or Storybook and end-to-end runs side by side. A summary check rolls them into one pass/fail status you can add to your branch protection rules. Three modes:

• Auto (recommended) — post a summary check only when a commit has more than one build.
• Always — always post a summary check, even for a single build. Useful when builds run conditionally, so the required check is always present.
• Never — don't post a summary check.