Get started with Verify

Test your app like a user would

Verify opens your app in a browser, tries real user tasks, and shows you what worked and what broke. You can watch it work and replay the results.

Start with a website URL. You don't need a repository or test scripts.

New Team workspaces are invoiced $500 upfront for 3,000 browser minutes. Your subscription renews monthly on your signup date, when your browser-minute allowance resets. Usage beyond the allowance is charged at renewal alongside the next month's subscription. Existing customers keep their current billing terms.

1 Add your app and explore it

1. Open Verify and add a project for your app.
2. Add the URL you want to test, such as your staging site. This is your environment.
3. If your app needs a login, add a test account. Use an account with data you are comfortable changing.
4. Start Discovery. Tell it which parts of your app to explore and what it is allowed to do.

Discovery explores your screens and user flows, then suggests tests. You can watch its browsers while it works.

Open an agent in Discovery or Deep Scan to see Observations first: pages visited and what each check observed. Diagnostics contains agent details, followed by activity and steps. Open Evidence at the right of the tab bar to load its recording, live browser, or saved captures and evidence files.

Testing an app behind a VPN? Connect your private network first.

2 Run your first test

Open Scenarios in your project. A scenario is a saved test, such as “A customer can add an item to their cart.”

Review the tests Discovery created, or write your own. Describe what the user should do and what should happen. Select a test, choose an environment, and run it.

Need to test a signed-in flow? Follow the login testing guide.

3 See what happened

Open the run to see its result and replay what the browser did. The replay timeline separates timestamped Events from duration bars in Phases. Select a tick or bar to seek to it. Recorded application cleanup appears on the Phases row, including retries and finalization time.

An unresolved step stays current until its checkpoint passes. When page text cannot be extracted, Verify can review the checkpoint screenshot, including during cleanup. Cleanup has its own limits and stops if it exhausts them or stops making progress. Its result stays separate from the scenario result: successful cleanup does not turn an incomplete test into a pass.

For browser scenarios that check hover changes, Verify can move the pointer without clicking and retain screenshots before and after the move. Captures can also sample an animation already running. These frames help compare changes such as growth and tilt. Missing frames or an unclear comparison leave the outcome unconfirmed; sampled frames do not prove continuous motion.

The scenario picker shows 25 executions per page. Choose a scenario to open its full report, steps, recording, and diagnostics. Links to a specific browser open that execution directly, including on later pages.

Scroll the center pane to read evidence and diagnostics beneath the player. As the player leaves view, it moves into a floating mini-player and playback continues. Click the window’s traffic lights to pop it out manually and smoothly scroll to the content beneath it. Scroll back up to its original place or click the mini-player’s traffic lights to return it to the page. With reduced motion enabled, the content appears immediately. Scenario runs, exploration threads and finding recordings use the same player controls; only one mini-player appears at a time.

Click or drag across the replay timeline to seek. Nearby video segments preload, and the last picture stays visible while a new position loads. Where supported, dragging uses fast keyframe previews; releasing the timeline or selecting a step seeks to the exact timestamp. Use the zoom slider on the right to inspect part of a long recording, and select Fit to show the whole recording again. Select a recorded timestamp or step to return to the player at that moment.

Verify automatically retries temporary browser-startup gateway failures up to three launch requests within the startup time limit. Recovery rejoins the same attempt without starting another browser or repeating test actions. Persistent startup failures leave the run incomplete; they do not count as an app failure. Visual review accepts small and resized viewports at their native resolution.

Use Scenarios → Runs to browse individual and grouped runs, newest first. Each row shows its trigger and execution date. Pull request runs also show the PR number and title. Search by scenario or PR, or filter by status, trigger, or environment. Your filters stay selected as you browse older pages.

The environment picker searches names, addresses, types, branches, and PR numbers. It lists regular environments first and Previews below, with up to 25 matches per group. Keep typing to narrow the results. You can also search archived environments to find historical runs.

The timing pill shows runtime | browser time in minutes. Runtime measures how long the scenario took. Browser time adds the time used by all metered browsers, including setup and sign-in: five browsers running for two minutes consume ten browser minutes. Usage appears as unavailable when its records are no longer retained. Open a run to investigate it; its back link returns to the list you came from.

• Passed: the tested outcomes worked.
• Failed: something did not match the expected result. Open the finding to see the evidence.
• Blocked or inconclusive: Verify could not finish or confirm the result. Read the reason, fix the setup if needed, and try again.

A passing run covers the tests it ran. It doesn't mean every part of your app has been tested.

Organization admins can choose Update Scenario beside the run’s scenario summary. Describe what should change, then choose Suggest Changes or press ⌘Enter on Mac / Ctrl+Enter elsewhere. Review the changed steps and outcomes. Edit opens the full proposal for manual changes; Refine lets you request another revision.

Save records a new revision. Save & Run saves and starts just that scenario in the displayed environment. The original run keeps its definition and results. If the scenario changed while you were editing, compare with the latest version before saving. Closing the form preserves your draft.

Test pull requests automatically

Once you have tests you trust, connect your repository in PR Testing. Choose when tests run and where the preview URL comes from. Verify tests relevant scenarios against the preview and posts the results to your pull request.

Set up GitHub preview testing or connect GitLab.

Look for more bugs

Use Deep Scan when you want Verify to investigate beyond your saved tests. Give it a goal, such as “Check whether customers can cancel a subscription.”

Deep Scan can consult bundled security and QA skills while it investigates. It selects relevant guidance for the task: dogfood for broad functional testing, exploratory-testing for deeper hypotheses and state transitions, break-ui for realistic worst-case data, ux-heuristics for usability and recovery, webapp-testing for browser observation, and security-audit for security boundaries. To request a skill in your goal, write its name with a dollar sign, such as Use $break-ui to check long names and empty states. The agent reads supporting references as needed and tests through the scan's available controls and permissions. Cloudflare's security skill provides review guidance here; a full source-code audit requires source access and independent verification that this scan does not provide.

When sandbox coding is enabled for your organization, browser Deep Scan can also write and run scripts in its disposable VM with normal filesystem and network access. It uses uv for Python dependencies, npm/npx for Node packages, and CDP to connect to the scan's existing browser and signed-in session. Deep Scan stays within the assigned app and chooses the actions needed for its investigation, including creating, changing and deleting app state. It has no separate action allowlist or per-action approval step. It uses synthetic test records where practical and reports their final state. Script sources and command output are retained with the tester's report. When native sandbox coding is enabled, Linux desktop Deep Scan can use the same script and file tools in the app’s VM, alongside its GUI tools. Scripts run as the desktop user, and GUI input requires a fresh capture after a script changes state. Native apps do not imply a browser or CDP connection. macOS, Android, and authored desktop scenarios retain their existing controls.

Tell it what it may change and how long to spend. Review the findings and replay the evidence before deciding what to fix.

Each Deep Scan worker can use up to 2,000 action turns. The run may stop earlier when its goal is complete, work is blocked, or its time or evidence budget runs out. A partial result preserves saved observations and identifies unfinished work.

When live supervision is enabled, the coordinator stays active while its workers investigate. It checks their saved progress, answers requests for help, redirects stalled experiments and can stop a worker while preserving its observations. Workers must save regular progress reports. Repeated activity without substantive progress triggers a check-in and eventually a stop. The coordinator uses one of the scan's concurrent slots; a scan with one slot investigates directly. Cloud passkey accounts use one slot to preserve exclusive credential ownership. An incomplete scan with zero findings does not establish that the application passed its checks.

If a native desktop's control connection fails after bounded recovery, Deep Scan retires that worker and starts a replacement while time and tester slots remain. The original worker's reports, findings, steps, and evidence stay attached to the scan. The replacement receives the same assignment and a report handoff, then re-establishes app and fixture state on its fresh desktop. Unsaved local changes are not transferred. Replacement attempts use the existing lifetime tester budget.

For organizations using InferOptimal workers, overlapping Deep Scans share one permanent inference service. The first scan enables and starts it; the last scan disables it after its workers finish. The URL and key are reused on the next run. This integration requires native Responses support and qualified startup passthrough. Qualify the permanent service with a real screenshot-and-tool Responses request before use. Provider failures are reported without silently changing protocols or providers.

Select a tester to watch its live screen above the Observations, Diagnostics, and Evidence tabs. Changing tabs keeps the player connected. Scrolling it out of view opens the floating mini-player; its traffic lights return it to full size.

Open Summary to read the findings and their cited screenshots without loading every tester’s activity archive. Choose Load recording on a finding to open its recording and timeline. Each recording loads separately; if one fails, use Retry recording while keeping the rest of the summary open. Copied summaries include the cited evidence links even before you open a recording.

Describe the user outcome and the state changes you want challenged. For example: “Using disposable test projects, challenge whether saved edits survive project switches and restart. Look for lost text, stale files, and actions affecting the wrong project.” Supply a test account for signed-in workflows and say explicitly when creating, changing, or deleting test data is allowed.

Deep Scan can report an observed problem as suspected before an independent reproduction. Confidence and severity describe different things: review the evidence and uncertainty alongside the reported impact. Blocked or unexecuted work remains untested.

Keep your project ready

• Knowledge holds what Verify has learned about your app. Add any instructions or context it should know.
• Environments holds the versions of your app you test, such as staging or a PR preview.
• Credentials holds your test accounts.
• Settings → General lets you edit the project name, URL slug, website, and icon. Verifier Guidance controls terminology, behavior, reporting, and prioritization for new runs; leave a field blank to use its default. Your draft stays available when you switch sections while the page is open. Billing and Organization link to their organization settings pages.
• Environments → Messages is available when Composal enables Messages for your organization. Set the assistant's iMessage number and a configured Composal tester number on its Environment. It may also have a website URL. Then use iMessage steps in your scenarios. Sendblue needs an incoming message to open its reply window; a dedicated Photon line can start the conversation. Review messages and evidence in the scenario's run results.

Coordinate Scenarios across personas

Open Scenarios → Run Plans to connect reusable Scenarios into one workflow. For example, a submitter sends a receipt, a processor handles that same receipt in another account, and the submitter checks the result.

1. Choose New Run Plan, name it, and add the Scenarios. Each node has its own key; you can use the same Scenario more than once.
2. Add a handoff from a producer's After step checkpoint to a consumer's Before step. Name it, for example, “Receipt submitted.” Add a return handoff to resume the submitter after the processor finishes. Step numbers refer to the source Scenario's authored steps.
3. For multiple signed-in Personas, configure a session endpoint and JSON pointers that verify each account, or reuse the same identity probe from the source Scenarios.
4. Save the plan. Verify rejects missing steps, unavailable Scenarios, and handoffs that would leave participants waiting on each other forever.
5. Review the timeline, choose Run, and select an Environment. The result shows the original Scenario ownership, handoffs, outcomes, and evidence.

The timeline shows step sequence, not predicted duration. Gaps show where one Scenario waits while another acts. One browser coordinator executes ready steps in order while retaining each Persona's isolated session; background activity in an inactive session can continue. Handoffs work with concurrency one. A checkpoint releases the dependent step; it does not mark a Scenario as passed. Every required authored outcome must pass for the plan to pass.

Plans currently support Website Scenarios with up to four Personas, 20 Scenario nodes, and 100 executed steps including sign-in. Use the Environment's permitted origins when a workflow crosses applications; signed-in participants must be verifiable through the configured session endpoint. Participants that sign in receive account setup before their first checkpoint, including anonymous Personas with a later sign-in step. Signup journeys need a named actor with an explicit step that completes authentication. Narrative multi-step signup Scenarios remain runnable on their own; plans refuse them rather than create an account before their authored signup actions. Scenarios share the same-run context so the processor can use the submitter's receipt reference; they do not share account cookies. Cleanup runs after the coordinated journey, in reverse Scenario completion order, and its result remains separate from test results.

Each run retains its plan and Scenario definitions. Source edits require fresh preparation before launch. Rerun the whole plan to get a new attempt; a previous attempt cannot release a new attempt's handoffs. Runtime and retained browser usage remain subject to the run's time limit and normal browser billing.

Prefer your terminal or coding agent?

Install the CLI to run tests from your terminal, or connect your coding agent. You can also write scenarios as files and keep them in your repository.

See the scenario reference for test files and the CLI reference for commands, uploads, and local runs.

Optional cleanup

Use Cleanup (optional) in the Scenario editor, or add a cleanup: list to its YAML file. These instructions run after the checks pass or fail and have a separate result. Leave cleanup empty when none is needed; the agent does not invent deletion or state restoration. Browser shutdown and recording finalization still happen automatically. Cleanup can remain incomplete if time or access runs out.

cleanup:
  - Delete the draft created during this run.

When updating an uploaded file, omitting cleanup preserves saved instructions; cleanup: [] clears them. Keep deletion that the Scenario tests in steps.

Testing a desktop or Android app?

Choose Computer use when creating your project. These tests need a supported desktop image or Android APK instead of a website URL. Read about the Verify agent and supported environments.