---
title: Browser checks: run your Playwright tests as monitors
description: Your login page can answer 200 while nobody can actually sign in, and an uptime check will never notice. Browser checks run your real Playwright test on a…
canonical: https://watchfor.io/changelog/2026-09-29-playwright-browser-checks
---

[All updates](/changelog/page/2#2026-09-29-playwright-browser-checks) ✨ New Playwright Sep 29, 2026 · v 8.9.5

# Browser checks: run your Playwright tests as monitors

Your login page can answer 200 while nobody can actually sign in, and an uptime check will never notice. Browser checks run your real Playwright test on a schedule in a sandboxed Chromium: sign in, search, check out, step by step. Every run shows step timings, screenshots, errors and Web Vitals; failures keep a Playwright trace. A retry and a confirmation run come before any alert, and neither counts against your plan. Start from a working example, paste codegen output or a Chrome Recorder export, or ask your agent. One hourly check is free.

Start from a working example and test-run it before you save.

A failed run shows the step, the error, a hint, the code and the page at that moment.

## Why

An HTTP check proves a page answers. It can't tell you that the Sign in button stopped doing anything after a deploy, that the cart empties itself, or that search returns nothing. A browser check does what a customer does, one step at a time, and tells you which step broke.

## Plain Playwright, nothing to learn

A check is a Playwright Test file in TypeScript or JavaScript: test , expect , test.step , test.use , fixtures and request all work. The same file runs on your laptop with npx playwright test , and [Run locally](/docs/monitors/browser-checks/run-locally) lists the exact versions and config. Every run shows the Playwright, Chromium and Node versions it used.

## Three ways in

- Start from a working example : page loads cleanly, login, login with 2FA (TOTP), search, checkout, API + UI, or blank. Each one passes on a public practice site on its first test run; Use my site switches it to your URL and your variables.

- Import a script : paste npx playwright codegen output or a .spec.ts file, or drop a Chrome DevTools Recorder export. The recording becomes editable Playwright code that you own.

- Ask your agent : Claude, Cursor or any MCP client can write the script, test-run it and create the check. See [Agents](/docs/monitors/browser-checks/agents).

Click Test run before you save and watch the steps tick past; a result usually arrives within 10 to 20 seconds.

## What a run shows

- Every step with its duration, a screenshot, and the error in one line when it fails, with a hint for common mistakes such as strict-mode violations or a locator that timed out.

- Console errors, failed requests, and TTFB, FCP, LCP, CLS and INP for each page the run opened.

- A comparison of a failed run with the last passing one: each step's change in duration and both screenshots side by side.

- The Playwright trace in a trace viewer hosted by WatchFor, so the trace never goes to a third party.

## Secrets stay secret

Put passwords and TOTP secrets in Settings › Variables & secrets as secrets. They are encrypted at rest, never shown again, read by the script as process.env.NAME , and masked in logs, error messages, step titles, trace text and screenshots of every scheduled run, not only in the editor.

## Flaky moments don't page anyone

A failed test is retried once in a fresh browser within the same run. A failing run is confirmed by a second run about a minute later, from another location when the check has one, before an incident opens. The retry and the confirmation run are not counted against your plan. Optional alerts cover a slow journey, per-step budgets, console errors, failed requests, slow LCP and flaky runs.

## Safe by design

Each run gets a fresh, disposable, sandboxed browser with memory and time limits. It can reach the public internet only; requests to private addresses are refused.

## Plans

Free includes one browser check running hourly from one location. Each paid plan has a monthly runs budget that your checks' schedules share: Starter's 9,000 runs are 2 journeys every 10 minutes, Pro's 45,000 are 5 journeys every 5 minutes or 10 every 10, and Business's 110,000 go down to every minute. Higher plans also allow longer runs and more test runs an hour. The [pricing](/pricing) table has the numbers.

A check never runs twice at once: its timeout has to fit its interval, and a scheduled run that comes due while the previous one is still going is skipped, never counted as a failure.

## From code

The REST API, the SDKs and the MCP server can test-run a script, list runs, read a run with its steps and errors, and create or update checks. See [API, MCP and SDK](/docs/monitors/browser-checks/api).

Start with the [quickstart](/docs/monitors/browser-checks/quickstart), or read [how browser checks work](/playwright-monitoring).

Share this update

---

Canonical page: https://watchfor.io/changelog/2026-09-29-playwright-browser-checks · Site guide: https://watchfor.io/llms.txt
