Runs from a schedule, from CI and from your own suites all land in the same project, with the evidence attached. The app is where you clear what needs a person and see whether the release is safe.
What you get
The app is built around one loop. Everything else on this page is a detail of it.
The runs happen without you
Scheduled suites, per-deploy smoke and anything your pipeline triggered have already finished by the time you open the app.
You open one list, not ten dashboards
Findings that need a person are at the top, newest first, each with its severity and the run that produced it. Nothing closes itself.
You confirm or dismiss, with the evidence open
Open a finding and the video, the failing step and the logs are already attached. Confirm it and it becomes an issue in your tracker.
You decide whether it ships
Suite health, the tests most at risk and what has not run since the last deploy are on the same screen as the queue.
Every case carries its own history, so a red run is read against how that case normally behaves rather than argued about from memory.
Every run is recorded. The recording sits next to the verdict, the runtime evidence and the reasoning, so a developer gets the whole thing in one link.
One project holds all of it, so a finding, the run behind it and the case it came from are always one click apart.
Findings
The review queue, with severity, age and the run that produced each one.
Tests
Cases in plain language, their pass rate, flakiness score and duration.
Executions
Every run in one list, whatever started it, with its evidence kept.
Pipelines
CI results pushed from Playwright or any other suite, next to Certyn runs.
Suites
Smoke, regression and exploratory grouped, scheduled or triggered on deploy.
Ask Certyn
Plain-language questions answered from your own runs, with links to them.
No. Connect TestRail, Zephyr Scale, Xray or Azure Test Plans and Certyn pulls the current cases at run time, so your tool stays the source of truth. You can also keep cases in Certyn if you would rather have one place. Both work, and they work together.
It does not have to. Push results from Playwright or any other suite and they appear on the same page as Certyn runs, so one screen answers what the last commit did. Plenty of teams keep their CI dashboard and use this for the review queue.
Whoever is on the hook for the release. QA engineers use the queue and the test health; developers usually arrive through a link on a pull request; managers open the board on release morning. It is the same data either way.
It stays open. A finding is only closed by a person, even if the next run passes, because a pass after a failure can be timing. The queue shows the age of each one so old items are visible rather than quietly forgotten.
In your project, on Certyn infrastructure, and they are only reachable by people in your workspace. If that is not acceptable, runs can execute on your own self-hosted runners instead.
Yes. The same answers come back in Slack, on a pull request, and through the MCP server from Claude, ChatGPT or Cursor. The app is the full picture, not the only door.
The daily loop
How the queue is meant to be worked, and what to do with each state.
Scheduling tests
Nightly regression, per-deploy smoke, and what to run where.
Live sessions
Watching a run as it happens, and what the recording keeps.
Quality metrics
How pass rate, flaky rate and quarantine are calculated.
Start on the free tier, no card. Point it at a staging URL and it drafts your first tests.
