Check whether Zerocheck fits your test flow

Zerocheck tests the web flows and expected outcomes your team describes. Start with a reachable environment, known test data and a result you can observe in the browser.

Requirement	Current support
Desktop web testing	Chromium browser runs.
Plain-English authoring	Add one test or import a checklist; review, edit and save the steps.
Hosted execution	Run from the web app with no installation in your codebase.
Localhost and private networks	Use the CLI's local runner where your machine can reach the app.
Login	Configure login steps and named test credentials.
CI	Run the CLI in a job you write. JSON run record and exit codes; no workflow generator, PR comment or JUnit report.
Schedules	None built in. Use your own CI system's schedule.
Coding agents	An agent can run the CLI and read the exit code and JSON run record. No MCP server.
Explicit outcomes	Supported text, URL and network assertions; AI interpretation for other descriptions.
UI maintenance	Find a moved control again, and record the old and new target.
Additional websites and embedded frames	Ordinary HTTP(S) navigation and embedded frames work with no configuration. An optional allowed_origins list restricts interaction to the app origin plus the exact origins listed; with a restriction set, each ancestor frame must also be allowed.

Checkout and cross-origin login

Use a confirmed payment test environment, fresh identities and explicit browser outcomes. Zerocheck supports embedded checkout, including Stripe's card fields, with no origin configuration. Set allowed_origins only when you want to restrict where the agent may interact, and then include every origin the flow needs; public third-party resources can load without becoming permitted interaction destinations. Hosted private-network restrictions apply independently. We try your purchase and decline flows with you during setup. A pass in a local browser doesn't guarantee a pass in the hosted one, so try the one you plan to use. Both runner types can encounter bot protection.

Additional interaction origins do not authorize configured credentials to leave the app origin. Environment secret_origins can grant each named credential an exact additional destination, only during configured login steps; when allowed_origins is set, that destination must be listed there too. The app origin remains the default. Body steps retain app-only permission. Settings saves the same permissions for hosted runs; test instructions and model output cannot widen them. Public test-card fixtures and {{unique_email}} need no configured secrets.

The supported login shape is a same-tab redirect to an email-and-password page, followed by return to the app and a positive authenticated assertion. Compatibility with a particular identity provider isn't established until it has been tried with the browser you plan to use. These controls also aren't a network sandbox for the application itself.

Same-tab navigation and embedded controls are in scope. Popups, MFA, passkeys, social login, automated challenge solving and 3D Secure are outside the initial claim. Targets in additional origins are re-grounded on each run; persistent hints remain limited to the app origin. No Stripe API adapter, webhook verification or reset platform is provided.

Flows that need a narrower test boundary

Email and SMS inbox actions, magic-link retrieval, file uploads and downloads, native/mobile apps, API-only tests and canvas-only interactions are outside the current browser-step support. Browser-native login can work with supplied setup; a workflow that depends on retrieving a one-time code from an inbox needs additional preparation outside Zerocheck.

Zerocheck can interact with ordinary checkout pages using supplied test data. It does not supply a payment provider, test-card helper or guarantee that a production transaction is harmless. See test credentials and actions.

What a test result tells you

A passing test means its specified steps and expected outcomes passed in that run. It does not establish complete application coverage or diagnose every possible regression. A failed or incomplete run needs inspection of the test and its evidence.

The product does not crawl your app to discover a suite, infer tests from code changes, calculate a coverage/confidence score, or provide production incident alerts. Select the flows and test files that matter to your release.

Execution and editing limits

Tests run sequentially. The current product does not offer parallel sharding or additional browser engines.

A disabled intended control fails instead of healing to another control. Ambiguous remembered targets require a more specific saved test revision. Recovery is bounded by the step deadline, and Zerocheck does not repeat an action whose dispatch is uncertain. See results, retries and healing.

Tests created in the web app are edited there. Repository-managed tests are edited in YAML and are read-only in the web UI. Downloading a web test creates an independent copy; there is no automatic two-way repository synchronization.

Access

Each instance is provisioned by hand during onboarding, with one shared access password. There are no individual user accounts, invitations, SSO or roles, and anyone with the password can see every project on that instance. "Unlimited seats" means there is no per-seat charge; it describes pricing, not separate logins.

Zerocheck is US$500 per month, with US$500 in credits at sign up that cover the first 30 days and up to 1,000 test runs, for one project on a dedicated instance, with about 1,000 test runs a month and more by agreement. Bring the flows you actually need to the setup call.

Pricing · Book a setup call · First browser test