Browser checks

Make sure the app works, not just the server.

Run checks in real Chrome browsers for login pages, checkout flows, dashboards, and JavaScript-heavy pages that normal uptime checks cannot validate.

Catch blank app screens.: Single-page apps can return a successful HTTP response while the frontend fails to render. Browser checks wait for Chrome to load the page and verify what a user would see.
Watch revenue-critical flows.: Monitor the screens where failures hurt: signup, checkout, billing, login, and customer dashboards.
Script the steps that matter.: When a page needs interaction before it proves it works, use Playwright to click, type, wait, and assert on the final state.
Use the same incident workflow.: Browser check failures can alert the same channels as uptime, API, cron, and heartbeat checks, so frontend failures do not disappear into a separate tool.

Frequently asked questions

The short version. The docs have the details when you need them.

When should I use a browser check instead of an uptime check?: Use browser checks when you need JavaScript to run or need to verify rendered content, not just an HTTP response.
Can browser checks alert my team?: Yes. Browser check failures use the same alert channels as other OnlineOrNot checks.
Can I use Playwright?: Yes. Scripted browser checks use Playwright, so you can write checks with familiar locators and assertions.
What should I monitor with a browser check?: Use browser checks for customer-facing paths where a server response is not proof enough: login, signup, checkout, billing, dashboards, and JavaScript-heavy pages.

Start with the flow that would make the most customers write to support if it broke after a deploy.