By the time you open Certyn, the work has already happened. Scheduled suites ran overnight, per-deploy smoke ran on every push, and your own CI pushed its results in. Your job is the part that needs a person.
This routine takes 5 to 10 minutes and keeps signal high.
1) Review the queue
Start in Overview and review the items that need attention: needs-review, high severity, quarantined tests, or verification required.
Nothing here closes itself. A finding stays open until a person decides, even if the next run passes, because a pass after a failure can just be timing.
2) Triage new Issues
For each new issue:
- confirm severity and user impact
- decide whether it blocks a release
- open the evidence before deciding. The recording, the failing step, the console errors and the failed requests are already attached.
- link it to your external tracker (Jira/Linear/GitHub), which stays the source of truth for ownership
3) Verify fixes
When a fix is deployed:
- re-run the relevant process or test, or use retest on the issue itself
- confirm the issue is truly resolved from the new artifacts (screenshots, logs, session trace), not from the status alone
4) Keep Tests healthy
- quarantine tests that are consistently flaky, so they stop polluting run results
- split overly long tests into smaller checks
- update expectations when the product legitimately changes
5) Read the release signal
The same board carries suite health, the tests most at risk, and what has not run since the last deploy. If you are shipping today, that is your answer. See Release Readiness for the full checklist.
The same queue and the same answers reach you 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.