# Get started with Verify
Add your app, run your first test, and see what needs fixing.
## 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](/docs/verify/credentials). 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](/docs/verify/private-networks).
## 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](/docs/verify/guides/authenticated-journeys).
## 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](/docs/verify/guides/github-previews) or [connect GitLab](/docs/verify/source-control/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.
Multi-worker scans delegate from existing project knowledge without requiring a new application map. Native workers can reuse successful operating recipes for editor modes, command entry, fixtures and foreground input. They check current access and prerequisites before using a recipe from an earlier build.
Scans with at least three testers reserve part of their budget for independent reproduction and matched negative controls. A 25-tester scan reserves five validation slots. These workers investigate the saved candidates on fresh desktops and keep missing controls or unclear intended behavior as coverage gaps. A clean investigation wave can use its remaining slots to explore further.
Workers save observations incrementally. Recoverable native reporting errors pause input while the worker corrects its report on the same desktop. A report correction does not repeat completed application actions. Saved results remain available if the optional written summary fails, with unfinished coverage and cleanup clearly marked.
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](/docs/verify/credentials).
- **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](/docs/quickstart) to run tests from your terminal, or [connect your coding agent](/docs/agents). You can also write scenarios as files and keep them in your repository.
See the [scenario reference](/docs/verification) for test files and the [CLI reference](/docs/cli) 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.
```yaml
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](/docs/verify/agent).