Documentation
How to point Beryl at a URL, get plain-language tests generated for your app, run your project, and re-run it on a schedule so regressions never reach your users.
Last updated: April 2026
1Introduction
1.1What is Beryl?
Beryl is automated testing and reliability from a URL. You hand over a URL and Beryl crawls your app, turns the flows it finds into readable tests written in plain language, runs your test project, and re-runs it on a schedule, comparing each run to the last so regressions never reach your users.
There is nothing to install and no complex setup. Beryl runs entirely in our infrastructure, so there is no SDK in your repo, no required CLI, and no selectors or XPath to maintain. The tests are readable end to end: buttons get clicked, forms get filled, and flows get executed exactly the way a real user would.
Core value proposition
Real end-to-end coverage of your app without writing or maintaining a line of test code. Enter a URL, get tests, and let Beryl re-run them for you so drift and regressions surface before your users hit them.
1.2How It Works
Beryl takes you from a URL to a running, scheduled test project in a few steps:
- 1Enter your URL: Drop a URL into Beryl. There is nothing to install and no code to write — Beryl runs entirely in our infrastructure.
- 2Beryl crawls your app: Beryl explores your app the way a user would, discovering the pages and flows it contains.
- 3Tests are generated: Each flow becomes a readable, deterministic test written in plain language — no selectors, no XPath, no code to maintain.
- 4The project runs: Beryl executes the project against your app, clicking buttons, filling forms, and running flows end to end, then produces a detailed report.
- 5Re-run on a schedule: Beryl re-runs the project on your schedule and diffs each run against the previous one, so regressions never reach your users.
1.3Key Features
| Feature | Description |
|---|---|
| Instant URL Testing | Drop in a URL and Beryl automatically generates natural-language tests for your app. Nothing to install — and an optional CLI/MCP for terminal, CI, and coding-agent workflows. |
| Plain-English Tests | Tests are written in plain language — no selectors, no XPath, no code to maintain — yet run deterministically. |
| Real Coverage | Buttons get clicked, forms get filled, and flows get executed exactly the way a user would do it. |
| Detailed Reports | Every run produces a clear, readable report showing which tests passed, which failed, and how long they took. |
| Run Diffs | Each run is compared to the previous one so you can spot exact changes and newly discovered flows instantly. |
| Automated Schedule | Beryl re-runs your whole project on a schedule, giving you a fresh baseline and a pass-rate history over time. |
| Regression Detection | Because every run is diffed against the last, regressions surface before they reach your users. |
2Getting Started
2.1Enter Your URL
Getting started is as simple as entering the URL of the app you want to test. Beryl immediately begins crawling, discovering the pages and flows in your app, and generating tests for them. You can watch the crawl happen live and see the tests appear in place.
2.2Review the Generated Tests
Once the crawl completes, Beryl presents the tests it generated for the flows it found. Each test is written in plain language describing the steps a user takes, so anyone on the team can read it — there are no selectors or code to interpret.
From here you can run the project and review the results. Every execution produces a detailed report (see Section 3).
2.3Testing Login-Gated Pages
Many of the most important flows live behind a login. Beryl can sign in to your app so it can crawl and test the pages your users see once authenticated, then exercise those flows the same way it does public pages.
3Reports and Diffs
3.1Run Reports
Every time your project runs, Beryl generates a comprehensive report. The report gives you a clear visual breakdown of the run: which tests passed, which failed, and how long each took — without digging through messy CI logs or test-runner output.
3.2Run Diffs
Beryl compares each run to the one before it. Today's run is diffed against yesterday's, so you can see exactly what changed and which flows are newly discovered. This is how regressions surface immediately rather than weeks later in a customer report.
4Scheduling
4.1Automated Daily Runs
Production drifts after you deploy. Beryl re-runs your whole project against your app on a schedule — every day, with no one watching and no manual trigger. You always have a fresh baseline to compare against when something looks off.
4.2Tracking Reliability Over Time
Running on a schedule means Beryl builds up a pass-rate history for your app. At a glance you can see whether your production environment is staying stable, and the run diffs tell you exactly when and where something changed.
5CLI & MCP
5.1The Beryl CLI
The web app needs nothing installed. For terminal workflows and CI, there is an optional CLI. Setup is one command:
npx @beryl-so/cli@latest init
It signs you in, pins the repo to a project, and wires up your coding agent. In CI, gate deploys on your suite — the exit code is 0 when every test passes and 1 otherwise:
beryl runs trigger --url-override "$PREVIEW_URL" --watch
The full command reference lives at /docs/cli.
5.2MCP for coding agents
beryl mcp runs an MCP server that exposes every command as a tool, so agents like Claude Code and Cursor can create projects, trigger runs, and read results. beryl init configures this automatically (.mcp.json / .cursor/mcp.json).
6FAQ
6.1Do I need to install anything?
No. There is no SDK to add to your repo. Beryl runs entirely in our infrastructure — you hand over a URL and start testing. If you prefer the terminal or want to gate CI deploys, the optional Beryl CLI covers everything the web app does, and doubles as an MCP server for coding agents.
6.2Do I have to write or maintain test code?
No. Beryl generates the tests for you from your app, and they are written in plain language with no selectors or XPath. There is no code to maintain as your app evolves — re-crawl and Beryl picks up the new flows.
6.3How does Beryl catch regressions?
Beryl re-runs your project on a schedule and diffs each run against the previous one. A flow that passed before and fails now shows up immediately in the run diff, so regressions surface before they reach your users.
6.4Can Beryl test pages behind a login?
Yes. Beryl can sign in to your app and crawl and test the flows your users see once authenticated.
7Support
Need a hand? Browse the support centre for guides on getting started, scheduling runs, reading reports, and managing your account, or reach the team directly at [email protected]. We respond to all requests within one business day.