What the platform actually does, in the order you'll actually use it.
Four things it actually does, not a feature list. Runs your existing tests across formats. Lets an agent trigger them directly. Schedules them on a real calendar. Keeps it all scoped to the right team.
One ordered Plan, every format you already have
A Plan is an ordered sequence of steps. Each step can be any type the platform supports, so you don't pick one format and migrate everything to it. Bring your tavern contract tests, your Hurl checks, a Bruno collection, a Playwright spec, even a raw pytest or cargo invocation and sequence them together as they are.
- Eight types today: tavern, hurl, bruno, playwright, playwright-lite, sql, ai_conversation, and adhoc
- Failure handling works at both levels stop the whole Plan on one bad step, or mark a group "ok to fail" so it doesn't block the rest
- Plan runs are checkpointed. A server restart mid-run picks up from durable state instead of losing progress
A real MCP surface, not a chat wrapper around a UI
Click a button in the dashboard, and there's a matching MCP tool an agent can call instead in the same session it's already writing code in. It's not a separate "AI mode" bolted on afterward.
- Author:
write_test_fileandvalidate_test_filecheck syntax per format before anything saves - Run:
run_testorrun_plan, then pollget_run_result. Same path a scheduled trigger uses - Query:
list_run_historyandget_plan_runsan agent can check what actually happened, not just what it thinks it triggered - Manage: full Plan and Environment CRUD, so an agent can build a whole test surface, not just fire one existing test
- Runs stay inside your own network a self-hosted Agent dispatches the actual subprocess under a second sandbox layer (Landlock LSM) on top of container isolation, so an agent-triggered run never gets a weaker sandbox than the platform's own
> run_test(suite="hurl", target="self_test.plans_list", environment_id=2)
{run_id: "hurl-03c7b4"}
> get_run_result(run_id="hurl-03c7b4")
{status: "done", passed: true}
Real RFC 5545 recurrence, not a cron string with a UI on top
Full recurrence syntax, built on the same RFC 5545 library the poll loop uses to trigger runs. The preview can't disagree with what actually fires it's one engine, not two.
- A specific day of the month, or a relative one. "The 15th" and "the last Friday" both work, not just weekly-by-day
- A real time of day, anchored to an IANA timezone. 9am stays 9am through a daylight-saving transition
- End conditions: run forever by default, stop after N occurrences, or stop on a date
- An advanced raw-RRULE mode sits next to the builder for anything custom
2026-02-27T17:00 EST
2026-03-27T17:00 EDT ← DST, still 5pm local
One org, many projects, roles that mean something
Multi-tenant and multi-project from one account, with role-scoped access instead of a shared admin token everyone uses.
Isolation is enforced at the request layer every route resolves tenant and project before touching data, not after. We keep tightening it as real usage turns up new edges.
| Role | Can do |
|---|---|
| Observer | See results and history never source, never write |
| Operator | Run tests and Plans, read results and history |
| Maintainer | Everything Operator can, plus create/edit Plans, Environments, Schedules |
| Owner | Everything Maintainer can, plus org/project settings and membership |
Curious how this stacks up against what you're using now? See how we compare to TestRail or testRigor →
See it run against your own tests.
Bring one real suite. Watch it pass in a Plan alongside everything else.