Everything you check after a deploy, in one tool

Browser tests are the core. The checks around them are included, so a release check does not need five tools. Here is what each part does, how it works and where its limits are. Availability depends on plan.

Record in Chrome

SpinUI Recorder is a Chrome extension that turns what you do on your site into test steps.

Every plan. Conditions, saved variables, optional steps and data tables are on every plan. JavaScript steps: Individual and up.

One site at a time. Chrome asks for access to the site when you start recording on it. You can remove that access in Chrome at any time.
Steps without code. SpinUI writes steps for your clicks, typing, selections, key presses and page addresses. Each element gets a main selector and backup selectors, so a test can still find an element when its main selector stops matching.
A clean window. Recording opens in a fresh private window by default, so your own logins stay out of the test. You can switch to your normal window in the extension options.
Sensitive fields are redacted. Password and hidden fields, and fields that look sensitive such as one-time codes, are redacted in your browser. You pick a stored secret in SpinUI instead.
Checks while you record. Add checks as you go, and accept or dismiss the checks SpinUI suggests. You can also re-record a test to replace its steps.
Logic when you need it. Run steps only if something is shown, save text from the page as a variable, mark a step optional, or run a test once for each row of a data table. JavaScript steps cover what those cannot.

Good to know. Do not record pages with real card data. A card-number field without an autocomplete value is not redacted.

Cloud or private runners

Run tests in our cloud, or on a runner inside your own network.

Cloud runs: every plan. Private runners: Team and Business.

Cloud runs. They use Chromium and run in our hosted service in the United States. Cloud runners cannot reach private or internal addresses.
Private runners. A private runner is a small service you install on your own computer or server, on Windows or with Docker. It connects out to SpinUI over HTTPS, so you open no inbound ports.
Your network. A private runner sees what its computer sees, so it can test an intranet or a staging site behind a VPN. It receives the secrets a test needs only for that run, and keeps them in memory.
More browsers. A private runner can run Firefox and WebKit as well as Chromium, where you install them.
No cloud minutes. Runs on a private runner do not use your included cloud minutes.
Evidence for every run. Each run keeps screenshots and a trace; video on paid plans. How long they are kept depends on your plan.

Good to know. Cloud runs are Chromium only. Firefox and WebKit are not available in the cloud.

Email testing

Test the sign-up, password reset and one-time-code emails your app sends.

Individual and up. Each plan has a monthly allowance of received emails.

An inbox for each run. Put {{email.address}} in a Fill step, and SpinUI swaps in the run’s own address. It is not a permanent mailbox: it accepts mail during the run and a short time after.
Wait for the message. Add filters on subject or sender if you need them. The step waits for a message that arrived after the run started.
Open it or click through. Show the email in the run’s browser, or click a link in it by its text or address.
Extract a code. Read a one-time code from the message into a variable, then type it in a later step.
Check the message. Check the subject, sender, recipient, text and attachments.
See everything that arrived. The run page lists every email received, including ones that did not match a step. Use labels if a test needs more than one inbox.

Good to know. Raw messages are kept for up to 72 hours by default, and an admin can shorten that. Codes are masked in results, but traces and videos show the page as it appeared, including any code on it.

Crawl, accessibility and visual checks

Find broken pages, accessibility problems and layout changes without writing more steps.

Every plan. Crawl length and page limits depend on your plan.

Site crawl. A crawl follows links from your start address, page by page. It reports broken links, redirects, missing or duplicate titles, missing meta descriptions, images without alt text and slow pages.
Polite by design. It obeys robots.txt unless you turn that off. It only follows links: it never fills in forms or clicks buttons, and it skips links that look like signing out or deleting. To crawl behind a login, run your shared sign-in steps first.
Accessibility check. It runs axe-core on the page as it is at that point in your test. Choose a standard from WCAG 2.0 A to WCAG 2.2 AA, and each problem comes with a how-to-fix view.
Visual check. It compares the end of a test with a screenshot you approved. The first run proposes a screenshot, and once you approve it, later runs are compared against it. Set a tolerance, and paint out areas such as a clock or an ad.
Separate baselines. Each browser, device and screen size keeps its own approved screenshot, so a phone is never compared with a desktop.
Other page checks. Check for no browser errors, page load time, and the network requests a page made.

Good to know. Automated checks do not prove WCAG conformance. They find many common problems, not all of them, so keep checking with people too. The visual check compares the visible screen at the end of the test, not the whole scrolling page.

AI that suggests, you approve

AI drafts and explains. A person decides what changes.

Every plan includes an AI allowance; higher plans include more.

Suggested checks. After you record, AI proposes extra checks based on the page text the recorder saw.
Why did this fail? A short, plain explanation of a failed run: the likely cause, what probably changed and what to try.
Selector fixes. When a step’s selector stops matching, AI can suggest a new one. You promote it or dismiss it.
Describe a test. Type what a test should do and edit the draft. Nothing is saved until you save it. AI can also suggest accessibility fixes, and point out pages your tests never visit.
You stay in charge. AI does not change your tests by itself. A person promotes or dismisses each fix.
What goes to Anthropic. Only minimised extracts, such as step labels, page paths, titles and short text snippets. Never screenshots, videos, traces, secrets, password values, cookies or test emails. Under our terms with Anthropic, it may not use them to train its models.

Good to know. AI can be wrong. A failure explanation sees a small summary of the run, not the page, so treat it as a hint. When your monthly AI allowance is used up, tests keep running and AI waits for the next month or an upgrade. Typed field values are sent for suggested checks only if an organization admin turns that on. It is off by default.

Pipelines and coding agents

Start suites from your pipeline, a deploy script or a coding agent.

Trigger URLs and CI tokens: Individual and up. MCP for coding agents: Team and Business.

Trigger URLs. A trigger URL starts one suite when another system sends it an HTTP POST. Use it from a deploy script, or from WordPress after a plugin update. SpinUI shows the URL once, and you can revoke it at any time.
One run, not five. Repeated calls while a triggered run is still waiting or running give that one run, so five plugin updates do not start five runs.
CI tokens. A CI token lets a pipeline start runs and read results through the API. We provide sample pipeline files for GitHub Actions and Azure Pipelines.
MCP for coding agents. Claude Code, Codex, Cursor, VS Code and Copilot can read your suites and tests, start runs and read why a run failed. An agent token works in one organization, with your role, and you can revoke it at any time.
Agents propose, you approve. Agents read and run by default. If you allow changes, an agent can only propose them, and a person approves each one in SpinUI before it can be applied.
Hard limits. An agent can never change your suites, schedules, environments, secrets, members or plan.

Good to know. The sample pipelines use the SpinUI command-line tool, which we have not published yet. Trigger URLs and the API work without it. Content your agent reads, such as website text and test emails, goes to that agent and its provider, not through us.

Client workspaces

Keep each client’s tests apart in their own workspace, and manage them from one account.

Team and Business. How many workspaces you get depends on the plan.

One workspace per client. An agency account can create a workspace for each client.
Kept apart. A workspace is a normal SpinUI organization. Its suites, tests, runs, results, secrets and people belong to it alone.
Nothing leaks across. Nothing is shared with the agency. Someone sees both only if they are a member of both.
Your team, and theirs. Agency admins can add themselves to a workspace, and invite the client’s own people from inside it.
One bill. Workspaces are billed to the agency. Allowances such as cloud minutes and AI are shared across the agency and its workspaces, not multiplied for each one.
On the record. Creating a workspace and adding yourself to one are written to the audit trail of both organizations.

Good to know. Workspaces go one level deep: a client workspace cannot create workspaces of its own.

Schedules and alerts

Run suites on a timer and hear about failures where your team already works.

Schedules and email alerts: every plan. Free has one schedule that runs at most once a day. Slack and webhook alerts: Individual and up. Teams alerts: Team and Business.

Pick a rhythm. Run every hour, every day, on weekdays or weekly, or use a custom cron expression. Runs can be as close as a quarter of an hour apart.
Pick what runs. Run all tests, tests with certain tags, or just the tests you choose, in an environment you pick. Scheduled runs can retry a failed test.
No pile-ups. A schedule never overlaps itself. If the last run is still going, the next one is skipped and the schedule says so.
Alert when it matters. Get an alert when a run fails, when it recovers, or after every run.
Where alerts go. Email, Slack, Microsoft Teams or a signed webhook. A message names the failed tests with the failing step, and links to the run.
Verifiable webhooks. Each webhook carries an HMAC-SHA256 signature you can check. Delivery is retried, so your receiver should cope with a repeat.

Good to know. Webhooks use SpinUI’s own message format. A receiver has to translate it for tools such as PagerDuty.

Check your site the way a person would

Record your first test by using your site.

Contact us Sign in