Skip to main content
No. Tests are written as sentences. The API and CLI exist for people who want to run them from a pipeline, and are entirely optional.
No. Testorim drives a real browser against your public address, exactly like a visitor. There is no script to embed and no agent to run.
Not directly. Private and internal addresses are refused, deliberately. Expose the build through a tunnel and use the public URL.
No. A saved test replays without planning, so the steps are fixed. Only the first, chat-driven run of a workflow is planned, plus a small number of calls for the report and for resolving a target that is not exactly named. That is why the advice is to save the tests you run repeatedly.
Chromium, through Playwright, headless.
Yes, up to your plan’s concurrent-run limit. Over it, a run is refused with a retryable error rather than queueing indefinitely.
The run stops and asks you, and continues with what you type, up to a 10-minute wait. This needs a person watching, so it does not work for scheduled or CI runs. For those, a session cookie in an environment or a login-setup test is the way.
No. Values typed into password-like fields are redacted before the run is persisted, before the report model sees them, and before a share link renders. Environment cookies and headers, database connections, browser cookies and saved login state are encrypted at rest.
Yes. A share link is a revocable, optionally expiring public URL to one run’s report, with credentials, environment headers, browser state and console/network detail stripped.
Because the action worked but something is worth knowing: the app moved the page mid-step, an Enter key was ignored and a click stood in for it, a target had to be inferred. Warnings do not fail a run; they are what makes a green run trustworthy.
Because it was not. A check you asked for that no step covers becomes a visible skipped step, and the run does not pass. Usually the test is doing too much, so split it.
Yes. A saved test exports as a standalone Playwright spec.
No. Trigger runs yourself with the API or CLI and read the result. The CLI’s exit code is 0 on pass, 1 on fail, 2 on error.
The workspace becomes read-only. Runs, reports and saved tests stay readable; nothing is deleted on cancellation.
According to your plan’s history retention. See the pricing page.