What plain-English browser tests replace, and what they don't

Some vendors sell browser testing as a replacement for a QA hire. Monito does not. A QA engineer decides what is worth testing, argues about severity, and holds a model of the product. Software does not take that job.

What Monito does is narrower. You describe what should work, in plain English. Monito proves it in a real Chromium browser, on a deployed URL or on localhost, and every verdict links to the screenshots, network log, and console output behind it. Nothing heals itself. When the product changes, you update the sentence. You do not update a selector, and Monito does not rewrite the sentence to stay green.

That is the labor it takes off a small team. It is not a hire.

What browser tests cover

For a team with no QA person, the missing work is usually execution: walk signup, login, the one action the product exists to do, and checkout, then read what happened.

A check covers that pass:

• You write the outcome you care about. "The form rejects a malformed email and explains why" is a check. "Test signup" is not.
• The agent drives Chromium and records the run: screenshots, console messages, and network requests (method, URL, status). Runs without a login record a video. Runs that sign in keep masked screenshots instead.
• The run ends Passed, Failed, or Error. Passed means the scenario's checks were observed. Failed means the app did not do what you wrote. Error means the check could not verify the scenario — the homepage calls that ending "cannot verify." An error is not a pass.
• On a failure or an error, the report names a cause when it has one: "App bug," "Test needs updating," "Site unreachable or access blocked," or "Monito's error — not charged."

You can run the same scenario again on a schedule, after a deploy, or from CI. The check command is the one-shot version. Saving it (monito check save) is how a check becomes a journey you keep proving.

What it does not cover

Judgment stays with you. Monito does not decide which five journeys matter, whether a failure should block the release, or what the product should do next. The note on when to hire is about that gap, not about replacing the person who owns it.

It also does not do the things a QA-replacement pitch implies:

• No self-healing. A changed path is a finding. See what self-healing tests actually mean.
• Chromium only. Not Firefox, Safari, native mobile, or a browser matrix.
• No ticket filed for you. A bug report can be copied as issue markdown (monito run view <id> --issue-markdown, or "Copy as issue" on the report). You paste it into Jira, Linear, or GitHub. Monito does not create the ticket.
• No production-user recording. The evidence is from Monito's own run, not from your visitors' sessions.
• Not a test framework. If you want tests as code in the repo, Playwright and TesterArmy's e2e are the fit. Test framework or hosted QA says when.

How often the verdict is right

Held-out benchmark, measured 2026-10-12: the right verdict was 58 of 60, with 0 false passes in 30 chances (95% upper bound 9.6%), 1 false fail, and 1 cannot-verify (Monito's own error, counted as wrong).

Our own corpus, measured 2026-10-05: the right verdict was 110 of 111, with 0 false passes in 57 chances (95% upper bound 5.2%), 0 false fails, and 88 of 111 verdicts cited every required observation. That corpus is ours, and it was used to tune the agent.

These numbers do not say how often Monito will be right on your app. The method and the limits are on the reliability page. Read the reliability page.

Who it is for

A small team that ships often, has no QA owner, and does not want a suite of selectors. The first useful step is one scenario on the flow that would hurt if it broke, then a verdict you can read. Sign up and run that check, or follow the check command. Prices are on /pricing.