Certyn keeps the critical flows under test and keeps the evidence. When you ask whether a release is ready, you get the failing tests, the open risks and what to fix first, with a link to the recording of each one.
Sounds familiar
The answer is built from runs that already happened, so it is checkable. Every claim links to the run behind it.
The critical flows stay under test
Sign-up, login, checkout and whatever else matters run on a schedule and on every deploy, in a real browser against staging or production.
Every result keeps its evidence
A failure is stored with a video, the failing step, console errors and repro steps. Nothing rests on someone remembering what they clicked.
You ask in plain language
In the dashboard or in Slack. No dashboard to learn and no query language, and you can ask a follow-up.
Also available in Slack and on a pull request
You get a decision you can defend
A readiness view with the failing tests, the high-risk issues, the coverage that is stale, and a recommended first fix. If it says not ready, it says why and points at the run.
Paste this into Ask Certyn in the dashboard, or send it to the Certyn bot in Slack. The answer comes from your own runs.
Before you start
Are we ready to release staging?
Show me:
- failing tests in the critical processes
- open major or blocker issues
- tests that have not run in the last 7 days
- anything flaky enough that I should not trust the result
Give me the one thing to fix first.Good follow-ups: "which of these are new since Friday?", "show me the video of the checkout failure", "what has not been tested since the last deploy?"
Findings arrive from scheduled runs and from CI, each one waiting for a person to confirm or dismiss it. Nothing closes itself.
These are records, not a monthly report someone assembles by hand.
Release readiness
Ready or not ready for a given environment, with the reasons listed.
Open risks by severity
What is broken now, how bad it is, and which flow it sits on.
Pass rate and flaky rate over time
Whether quality is improving or the suite is losing its credibility.
Stale coverage
Flows that have not been tested since the last deploy, which is the risk nobody reports.
Evidence for every claim
Video, logs and steps behind each failure, for audits and for arguments.
The same answer in Slack
Ask in the channel where the release is being discussed, not in another tab.
You pay for QA hours, not per seat. Free gives you one hour with no card, Founder is $99 a month for 6 hours, Team is $499 a month for 40 hours and 3 tests running at once. A smoke pass over the critical flows is minutes, so a nightly regression on a normal app fits inside a Team plan.
No, and be careful with any tool that says it does. It takes the repeatable execution off their plate. The people still own test strategy, exploratory testing, and the release call. Teams that get the most out of it usually keep the same QA headcount and stop losing them to regression passes.
Runs happen in isolated browser sessions and evidence stays in your workspace, scoped to your tenant. Use dedicated test accounts and staging data rather than real customer records. If your policy does not allow a shared cloud runner, you can run the runner on your own infrastructure.
Onboarding points Certyn at a URL, it explores the app and proposes the first tests, and you can run them the same day. One QA hour on the free tier is enough to cover sign-up, login and checkout and see real results before you decide.
Every finding ships with a video and repro steps, so confirming or dismissing it takes seconds and does not need a meeting. A bug also stays open until a person closes it, even if a later run passes, because a pass after a failure can be timing rather than a fix.
Yes, and many teams do a read-only smoke pass after each production deploy. Keep destructive flows on staging, and give the production environment its own account and data.
Release readiness
What goes into the answer and how to make it trustworthy.
Quality metrics
Pass rate, flaky rate and how to read a trend before a release.
Self-hosted runners
Run the browser sessions inside your own network.
Security
How data, credentials and recordings are handled.
Start free, no card. Point Certyn at staging and ask it a question by the end of the day.