TestPlanHQ
for engineering teams that can't afford a mistake

All your tests.
One Plan.

Stop stitching tavern, hurl, Bruno, Playwright, SQL, and AI-conversation tests together with cron jobs and hope. Run them all as one ordered Plan instead on a real schedule, or straight from your agent's own session and every result lands somewhere you can actually find it later.

8
test formats composable in a single ordered Plan
64
agent-facing MCP tools, day one
4
real RBAC roles, enforced on every route
1
ordered Plan replacing four disconnected pipelines
Straight from the app

Here's the same idea, running for real.

The real TestPlanHQ dashboard your tests, Plans, schedules, and webhooks, all in one place, screenshot taken straight off the product.

The real TestPlanHQ dashboard, showing the persistent sidebar navigation and org overview
Four jobs, not a feature list

What you actually do with it

01

Compose every test type into one Plan

Mix all 8 types freely in one ordered run: an HTTP contract test, a browser flow, a database assertion, an LLM conversation check. Each group sets its own failure policy, so one flaky step doesn't have to take down the rest. Outputs thread automatically into the next step's Environment no manual variable hand-off.

02

Let an AI agent run the whole lifecycle

The MCP server isn't a chat layer bolted onto the product. It's the same Project/Suite/Plan/Run/Environment lifecycle the UI uses, exposed as real tool calls author and validate content, trigger a run, read history, manage your org. An agent can operate this platform end to end today.

03

Automate on a schedule you can actually trust

Schedules run on real RFC 5545 RRULE recurrence. The preview you see while building a rule uses the exact same engine as the poll that fires it later so what you see is genuinely what happens, not a second implementation guessing at the same rule.

04

Multi-tenant, with roles that mean something

Every organization is a real, isolated tenant, and every member holds one of four roles Observer, Operator, Maintainer, Owner enforced on the same backend path whether the caller's a browser session or a token. Webhook payloads are HMAC-SHA256 signed, so a receiver can actually verify they came from you.

Where we actually stand

An honest status page, not a trust-badge wall.

Every route resolves the calling tenant and project before it touches any data, not after that's enforced on the main request path, not bolted on. We're actively hardening it this week as real usage turns up real edges, and we fix them in the open.

  • Tenant → Project → execution profile, resolved on every request, never assumed from a client header.
  • A dispatched run gets its own ephemeral container spun up, executed, torn down, never shared or reused.
  • An Observer role sees results and history never source, never write access enforced identically for a person or a token.
Tenant · acme-corp
project: checkout-api
run container #a12d
Tenant · northwind
project: billing-svc
run container #f931

Built for environments that can't afford a mistake real multi-tenant isolation, role enforcement on every route, an execution boundary that's architectural rather than a settings toggle. We test this platform with the same discipline we built it with.

Before you ask sales

Can I mix test formats in one run, or is this single-paradigm like most tools?
One ordered Plan can carry Tavern, Hurl, Bruno, Playwright, SQL, and AI-conversation steps together, with results flowing through in sequence to a single report at the end. It's a first-class design, not a workaround.
Can an AI agent trigger and read tests without a human in the loop?
Yes every REST route has an equivalent MCP tool, enforcing the exact same role the calling credential was issued. Agents don't get a side door around your access model.
Is my organization's data actually separated from other tenants, or just filtered in the UI?
Separated at the request-resolution layer: every route resolves the calling tenant and project before it touches data. Dispatched execution goes a step further and gives each run its own throwaway container, never shared or reused.
What happens if a step fails partway through a Plan?
Every group in a Plan carries its own fail policy stop the Plan there, or continue past it and keep running the rest, your call per group. Either way, the full step-by-step result is there afterward, nothing runs blind.

Stop maintaining four test runners to cover one product.

Start on the free tier 100 test cases, 500 runs a month, no card required.