What browser checks can and cannot see
What a headless-browser check records, how its sandbox and egress controls constrain it, what the screenshot evidence is good for, and why field data from real users is a different measurement.
By the UptimeMonitor360 team · updated
What runs
A browser check loads your page in headless Chromium on a probe that advertises the browser capability, then executes the steps you configured: navigate, click, fill, wait for an element, assert text, assert the URL, assert an element. There is no custom JavaScript step by design; everything the check does is declared in the monitor and visible to anyone with access to it.
What is recorded
Navigation timing (time to first byte, DOM content loaded, load), Largest Contentful Paint and Cumulative Layout Shift as lab values, console errors (up to 20, truncated to 200 characters), failed sub-resource requests, the number of requests, the final URL and title, the duration of each step and, optionally, a JPEG screenshot of at most 150 KiB kept for seven days. Filled form values are never recorded and URLs in evidence lose their query strings and credentials.
What the browser cannot reach
The browser never connects to the network directly. All of its connections go through an egress proxy inside the probe that applies the same destination policy as HTTP monitors and resolves names itself, so private networks, loopback, cloud metadata addresses and names that resolve to them are unreachable, including through redirects, iframes, popups and fetch calls. WebSockets, service workers, QUIC, non-proxied WebRTC, downloads and popups are disabled. Chromium runs with its sandbox on, as an unprivileged user.
What the numbers mean
Lab values from one probe location on a fixed machine are repeatable, which makes them good at detecting regressions: a page that took 1.2 seconds to load yesterday and 4 seconds today changed. They are not what your visitors experience on their devices and networks; that is what real user monitoring measures, and the two are shown separately and never averaged.
Allowances
Browser executions are metered per account and month because they cost far more than HTTP checks. Plans currently include no allowance until the cost model is approved; operators can grant contract allowances, and the scheduler records a gap instead of a run when the allowance is exhausted, so the dashboard never shows a check that did not happen.
Monitor the behaviour described here continuously: start free with 5 monitors or try the free tools.