Guide · monitoring and releases

Playwright synthetic monitoring vs a release QA check

First published November 10, 2026 · Facts checked November 10, 2026

Short answer

Use synthetic monitoring to learn that production broke after release. Use a release check to learn whether this candidate met the claims you wrote. A green monitor does not accept a candidate you have not checked.

On this page

Context and limits

A Playwright script can run in two jobs. Synthetic monitoring starts on a clock, opens production, and tells you when a journey breaks later. A release check starts because a candidate exists, and tells you whether the claims you wrote held before you ship. The same browser tool does not make those the same result.

Have a site ready to check? Test my site free. Add your URL and review a test plan before starting a run. See a sample report first.

Two jobs, even when the tool is the same

Playwright’s CI docs describe running a suite when a job starts. You can also schedule that suite yourself. Scheduling it against the published site, and alerting when it fails, is monitoring. Running it because you have a candidate, against that candidate’s URL, is a release check. Write down which job this run was, or the next person will read the wrong decision into it.

Hosted monitors, such as the product compared on the Checkly page, add schedules and alerts. That page holds the dated vendor facts. This guide does not restate prices or limits. The Playwright comparison is the choice between owning a suite and starting from a reviewed plan.

What each result is allowed to say

Monitor pass. The scheduled claims held on production at that time. It does not describe an unreleased branch.
Monitor fail. Production did not meet those claims on that attempt. It does not, by itself, name the deploy that caused it.
Release pass. The candidate URL met the claims you wrote. It does not promise production will keep meeting them tomorrow.
Release fail. The candidate missed a claim. It is not a production incident unless that URL is production.

A monitor that never runs your new journey cannot bless that journey. Add the new claim to the release check first. Add it to the monitor after you have decided the live behavior is the one you want watched.

Use both without mixing the records

A reasonable split: a release check on the candidate for the journeys this change can break, then a short check on the published URL after you ship, then the monitor you already trust for the journeys that must keep working. The guide to running a check on every deploy is the release side. The small-team regression routine is how you choose which journeys stay on the list.

Keep the records separate. A monitor alert is not a release verdict. A release report is not an uptime promise. If a row was blocked or not run, it stays open in whichever job produced it.

Common questions

Is synthetic monitoring the same as a release check?

No. Monitoring rechecks production on a schedule. A release check answers whether a candidate met the claims you wrote.

Can a Playwright suite do both?

Yes, if you start it for each job and label the run. The script does not know whether you are judging a candidate or watching production.

Does a passing production monitor mean the next release is safe?

No. It describes production as of that run. The next candidate still needs its own check.

Sources

Try Sybqa on your site

Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.

Add your site link here and it will be waiting in the console after you create an account. Then describe one journey to check and review the test plan before any run starts.