Getting started
How a Suite becomes a Plan, and a Plan becomes a Run. This is what the product does today, not what's on a roadmap.
Sign in to your first automated run
-
1
Sign in
A magic link is all it takes. It sets up your account and a personal organization at the same time no signup form, nothing to configure first.
-
2
Write a test
Choose a type tavern, hurl, bruno, playwright, playwright-lite, adhoc, sql, or ai_conversation and write it. We keep full version history, and only turn it into a real file right before it runs.
-
3
Build a Plan
String tests together as ordered steps. Nothing stops you from mixing types in the same Plan.
-
4
Run it, then automate it
Trigger the Plan by hand first and see what comes back. Once you trust it, add a Schedule to run it on its own, and a Webhook so you hear about failures the moment they happen.
The mental model
Project, Suite, Plan, Run
A Project is your top-level boundary. A Suite is a group you name yourself "smoke," "billing," whatever makes sense for your team and it can mix any engine inside it. A test's engine (tavern, hurl, sql, and so on) is its Type, not its Suite. A Plan strings steps from any Suite into an ordered sequence with its own pass/fail rules. A Run is one execution, whether that's a single test, a whole Suite, or a full Plan.
8 types, one contract
tavern writes HTTP flows in YAML. hurl does the same in plain text. bruno reads .bru collections. playwright drives a browser with real Python page objects; playwright-lite does it with JSON steps and no code at all. adhoc just runs pytest. sql checks assertions straight against Postgres. ai_conversation scores multi-turn LLM chats with a judge. They all speak the same plugin contract, so a Plan can mix any of them.
How a Plan composes steps
Any step can stop the Plan on failure or let it continue. Group steps together and set the policy per group instead of per step, if that's easier. No policy set anywhere? The Plan's own default takes over. And a skipped step still gets a real, visible record nothing just disappears.
Outputs flow between steps automatically
Declare an output on a step and its value lands in the next step's Environment before that step even runs. You never copy a token or an ID by hand between steps in the same Plan.
Environments hold your shared variables
Think URLs, credentials, tokens one named set any Suite or Plan can point at. Anything that looks like a credential gets redacted on screen. Editing one replaces the whole set; it never quietly merges over a value you'd redacted.
Schedules and Webhooks handle automation
A Schedule fires a Plan on a real recurrence rule. The same engine powers the preview you see while building it and the poll that actually runs it later, so there's no surprise. A Webhook posts to a URL you give it on events like a run passing, failing, or a Plan finishing signed, so you can trust it came from us.
Roles and organizations
Every Member gets one role per org: Observer just reads, Operator can run things, Maintainer edits Plans and Schedules and Environments, Owner manages the org itself. You're always working inside one active org at a time switch explicitly when you need another.
Personal Access Tokens and MCP
Mint yourself a PAT when you need programmatic or agent access. Over MCP, an agent gets the same lifecycle a human gets in the UI write and run Suites, build and run Plans, manage Environments, read history just as tool calls instead of clicks.
A few things people miss
- Declare an output on a step and it shows up in the next step's Environment on its own. You don't pass variables by hand.
- You can set failure policy per group, not just per Plan label a few steps, give that group its own on_failure, and let it tolerate failures the rest of the Plan wouldn't.
- Policy resolves step first, then group, then the Plan's default. Set it wherever it actually matters instead of repeating the same value everywhere.
- If a Plan run gets interrupted, it picks up from a checkpoint on restart. Steps already marked done or skipped won't run twice.
- sql doesn't need any extension on the target database. It connects with a plain Postgres driver, so you can point it at a live database with nothing extra to install.
- The Schedule preview and the real poll that fires it share one recurrence engine. What you see while building the rule is exactly what happens later.
Every field, every tool, every real gotcha
The exhaustive developer reference every suite type's real schema with working examples, the complete MCP tool surface, and the real traps this team's own dogfooding found lives inside the app once you're signed in.
Sign in for the full docs