When is a browser check worth it?
When the thing you care about only exists after JavaScript runs. An HTTP check on a single-page app fetches the shell, gets a 200, and tells you nothing about whether the app rendered, whether the login form submitted, or whether the checkout button called the right endpoint. A browser check drives the page the way a customer does and asserts on the state it reaches.
It is the most expensive check we run, which is why it is metered in minutes rather than included without limit. Use it for the two or three journeys whose failure would actually cost you money, and use HTTP and API checks for everything else. A fleet of thirty browser checks is usually a fleet of thirty HTTP checks wearing a costume.
How is browser-check usage measured?
In minutes of browser runtime on a rolling 30-day window. Starter includes 250 minutes a month and Team includes 1,000. The Free plan does not include browser checks.
A typical login-and-assert journey takes 10 to 20 seconds, so 250 minutes is roughly 750 to 1,500 runs. Running one such check every 5 minutes uses about 8,640 runs a month, which is well past the Starter allowance — so match the interval to the budget, not the other way round. Every 15 or 30 minutes is the right cadence for most journeys, because a broken checkout that is caught in 15 minutes is caught.
What evidence is captured when a check fails?
Each run can capture a screenshot at the point of failure, a trace of the steps the browser took, and the browser console output. Artifacts attach to the run and to any incident opened from it, so triage starts with what actually broke rather than with a reproduction attempt.
Console capture is the one people underuse. A page that looks correct in a screenshot but threw an uncaught TypeError on a background fetch is a page that is about to fail for a subset of users, and the console is where that is visible.
How long are artifacts kept?
About 14 days from capture, then they are deleted automatically. That window is deliberate: screenshots and HAR captures of your own pages can contain whatever was on screen, including customer data, so keeping them indefinitely would make us a long-term store of your users’ personal data for no operational benefit.
If a run matters beyond 14 days — a post-incident review, a dispute — download the artifacts from the run detail while they exist. Artifact links are signed and time-limited so they can be shared with a responder without giving them access to your workspace.
What should a browser check assert?
The state that proves the journey worked, not the steps that got there. Asserting that a specific button exists makes the check fail on the next redesign; asserting that the page after checkout contains an order number does not.
A good rule: if a human tester would say "yes, that worked" on seeing it, assert on that. If they would say "well, the page loaded", it is not an assertion worth having.