Certyn runs your real user flows in a real browser on every pull request. When something breaks you get the failing step, a video of the session, and the console and network logs. There is no test code to write and no selectors to keep alive.
Sounds familiar
No new repository, no page objects, no fixtures. One step in your workflow file and a URL to run against.
You open a pull request
The action starts a Certyn run against the environment you name: staging, a preview deploy, or production for a post-deploy check.
uses: certyn-one/action@v1
Certyn drives the app, not the code
It signs in and walks the flows you marked as critical, in a real browser. It reads the page the way a person does, so renaming a component or swapping a class does not break the test.
The result lands on the pull request
One check with the affected tests, pass and fail counts, and a link to the run. The check fails when a test fails or is blocked, so a broken critical path cannot merge quietly.
fail_on_failed: true · fail_on_blocked: true
A failure arrives with proof
Open the run and you get the video, the step where it broke, console errors, failed requests, and repro steps. Usually enough to fix it without reproducing it yourself.
This is the whole integration. Copy it into your repository and the next pull request gets a check.
Before you start
name: Certyn PR Smoke Gate
on:
pull_request:
branches: [main]
jobs:
certyn:
runs-on: ubuntu-latest
steps:
- name: Run Certyn smoke suite
id: certyn
uses: certyn-one/action@v1
with:
api_key: ${{ secrets.CERTYN_API_KEY }}
project_slug: my-app
environment_key: staging
process_slug: smoke-suite
- name: Add Certyn summary
if: always()
run: |
echo "## Certyn Result" >> "$GITHUB_STEP_SUMMARY"
echo "- Run: ${{ steps.certyn.outputs.status_url }}" >> "$GITHUB_STEP_SUMMARY"
echo "- Failed: ${{ steps.certyn.outputs.failed }}" >> "$GITHUB_STEP_SUMMARY"
echo "- Blocked: ${{ steps.certyn.outputs.blocked }}" >> "$GITHUB_STEP_SUMMARY"Not ready to define a process? Swap process_slug for tags: smoke,critical and it runs whatever carries those tags. Set wait_for_completion: false if you do not want the check to hold the pull request.
Certyn runs an MCP server, so the assistant you already code with can do the setup for you: create the project, write the first test cases, generate the workflow file above, and read back what a failing run actually saw. You describe what the product does. It does the wiring.
Before you start
claude mcp add --transport http certyn https://api.certyn.io/api/mcp \
--client-id tpc_nZvCVz9Wdh1yb7VX7VBzi4 \
--callback-port 8080
# then run /mcp inside Claude Code and sign in[mcp_servers.certyn]
url = "https://api.certyn.io/api/mcp"
env_http_headers = { "X-API-Key" = "CERTYN_API_KEY" }Cursor, Claude and ChatGPT connect to the same server. Once it is connected, questions like “which test failed on the last run, and what did the agent see?” are answered from the run's own evidence, in the terminal.
Runs triggered by the action sit next to results you push from Playwright or any other suite, so one page answers what the last commit did to the app.
Every run keeps its evidence, so debugging starts from what actually happened instead of from a guess.
Video of the session
Watch the whole run, or jump straight to the moment it broke.
Screenshot at the failing step
The page exactly as it looked when the check gave up.
Console and network log
The errors thrown and the requests that failed during the run.
Steps to reproduce
Plain text you can paste into a ticket or a commit message.
Run history
Whether this test passed yesterday, so you know if your change caused it.
A ticket, if you want one
File it to Jira, Linear or GitHub Issues with the evidence attached.
No. You describe a flow in plain language once, or let Certyn explore the app and propose the flows itself. Runs work from what is on the screen, so a refactor, a renamed class or a moved button does not send you back to fix selectors.
A smoke pass over a handful of critical flows usually takes a few minutes, and tests in a run go in parallel up to your plan limit. If you do not want the pull request waiting, set wait_for_completion: false and the result shows up in Certyn and in your notifications instead.
Environment variables hold the test account and any seed data, and Certyn signs in like a user would. Use a dedicated test account, not real customer credentials. For 2FA, use a staging account with a shared secret or a bypass.
Every finding carries a video and steps, so confirming or dismissing one takes about thirty seconds. Certyn also scores flakiness by how often a test flips result without a product change, and tests above 20 percent over at least 5 runs become quarantine candidates so they stop failing your build.
No. Certyn runs against a URL, so the workflow only needs an API key. Repository access is optional and only used if you want Certyn to hand a failure to a coding agent and open a fix pull request.
The action is a wrapper around the CI API. Any system that can send an HTTP request can trigger a run and poll for the result. There is a guide for other CI systems, with a plain curl example.
GitHub Actions
Every input and output, plus PR gates, post-deploy checks and nightly runs.
Other CI systems
GitLab, CircleCI, Jenkins and anything else that can call an API.
Writing test scenarios
How to describe a flow so a run does what you expect every time.
Fix with a coding agent
Hand a confirmed failure to an agent and get a pull request back.
Start on the free tier, no card. One QA hour is enough to cover sign-up, login and checkout.