Admin Dashboard & Metrics

Project history

A run can be started with an intent: a sentence saying what you meant to change, such as “updated the pricing copy”. When a run carries one, each changed page gets a verdict — whether that page's change is covered by the intent or contradicts it. A run started without an intent gets no verdict. See giving a run an intent.

Every project card on the Sites tab opens that project's history: each run on its own dated row, with what the run found. A run that carried an intent shows its verdict (“Changed, all cleared”, “1 contradicts intent”); one without shows its change count. Toggle Changed only to see the days something moved. A run opened from the history shows a back link at the top of the run, labelled with the project's name, that returns you to the history. The dots on a Sites card show the run's date on hover, and a quiet project links to its last change so the review workspace is one click away.

Job Status Lifecycle

Jobs transition through the following states, visible in the history badges:

• INITIALIZING: Preparing the environment and parsing target URLs.
• PROCESSING: Headless workers capturing and comparing screenshots in parallel.
• FINISHING: Every page has been captured and compared, and the run has not yet reached one of the states below. This is what you see in the gap, not a state a run stops in — keep polling.
• SUMMARIZING: Post-map AI summary is running, generating regressionbot summaries of visual changes.
• COMPLETED: Execution finished. Diff metrics, images, and regressionbot summaries are ready.
• APPROVED: Every page carrying a diff was reviewed and approved, and those pages were promoted to the baseline.
• RESOLVED: Every page carrying a diff was reviewed, and at least one was rejected. The run is finished with review; the rejected pages kept their existing baseline.
• FAILED: Execution aborted due to system or network issues.

A run reaches APPROVED or RESOLVED once every page carrying a diff has a decision. Pages with nothing to decide do not hold it back, so a 33-page run with one diff resolves on that one decision. RESOLVED is the common outcome whenever you reject anything at all.

Comparisons are the only thing metered. Every changed page gets a regressionbot summary — there is no separate summary allowance to run out of.

Triage Interface

Inside the triage view, you can compare the baseline and current versions of the page using:

• Interactive Comparison Slider: Click and drag the vertical slider left and right to compare the two screenshots.
• Side-by-Side View: Compare the baseline and current screenshots side-by-side (especially useful for layout changes or structural redesigns).
• Page View (V): Both captured pages, rebuilt side by side from saved snapshots. Changed elements are outlined and changed words are highlighted.
• Code View (C): A line diff of the page structure the engine compared, the HTML source, and the CSS.
• Text View (D): The page's text in reading order, with the changes marked.
• Runs from before page snapshots were saved have no Page view; they show the screenshots instead.
• AI-Powered Summaries: Read plain-English descriptions of detected regressions in the side panel (collapsible to prevent blocking screenshot details).
• Element Mask Overlay: View selectors configured to be hidden from comparison, showing how they were masked to prevent noise.
• The verdict: On a run that carried an intent, the verdict sits above the capture: the decision, its confidence, the basis it was reached on, and the words of the intent it cites, quoted. The button the verdict recommends — Approve or Reject — is outlined. Approving or rejecting against that recommendation asks once, optionally, what the verdict missed; you can skip the question. A run with no intent says so in the same place.

Creating one

Pick an existing project, or enter a name and URL to create a new site and schedule it in one step. Choose every day or every week, optionally a UTC hour, and the API key the runs will use. The key is required: scheduled runs have no request to draw a key from, and a run with no key cannot meter AI usage, so its summaries would be skipped and the alert would list changed pages without saying what changed. Saving puts a managed project on a rolling baseline — every run becomes the new baseline, and owners are emailed when a run finds changes. Live-vs-live projects keep their policy, since they store no baseline.

The standing intent

A scheduled run has no PR to say what it was meant to do, so on its own it is never judged. Each row carries a short intent — what the pages are expected to do between checks and what must not change — and every scheduled run is judged against it, the same way a PR run is judged against its description. It can be set when the schedule is created or edited on the row afterwards, and changing it never invalidates baselines. A row with no intent says so: its runs report “not judged” until one is written.

Removing one

Remove stops the unattended runs and nothing else: the project, its baselines and its history are kept, and it stays on a rolling baseline, so a run you start by hand still rolls forward. Schedule it again whenever you like — neither change invalidates baselines.

The tab is available to owners and admins; members do not see it, because choosing a key means seeing the key list.

Manage API Keys

Generate multiple API keys (e.g. sk_live_...) for separate CI pipelines, staging systems, or development environments. Keys can be toggled visible, copied, or deleted at any time.