Browser Monitors
Browser monitor support is in preview. Feature availability may vary by account tier.
A Browser Monitor runs your API or web endpoint through a real headless browser (Chromium, Firefox, or WebKit) instead of a plain HTTP client. This captures the full user-experience picture: how long the page takes to render, what errors appear in the console, and whether Core Web Vitals are within acceptable ranges. For an overview of browser monitoring capabilities including visual regression detection and HAR capture, see Browser Monitoring on the platform site.
When to use
Use a browser monitor when you need to:
- Measure real-browser load performance (not just raw HTTP response time)
- Capture Core Web Vitals (LCP, CLS, FCP, TTFB) for performance budgeting
- Verify that JavaScript-rendered content appears correctly
- Detect console errors or failed sub-resource loads that HTTP monitors miss
Core Web Vitals captured
| Metric | Full name | What it measures |
|---|---|---|
| LCP | Largest Contentful Paint | Time until the largest visible element loads |
| CLS | Cumulative Layout Shift | Visual stability — how much layout shifts during load |
| FCP | First Contentful Paint | Time until the first text or image renders |
| TTFB | Time to First Byte | Server response time before content begins |
| INP | Interaction to Next Paint | Responsiveness (where supported) |
Supported browser engines
| Engine | Notes |
|---|---|
| Chromium | Default; broadest compatibility |
| Firefox | Gecko engine; for cross-browser coverage |
| WebKit | Powers Safari; recommended for iOS-representative testing |
Setup
Step 1: Create a browser monitor
- In the sidebar, under CONFIGURE MONITORING, click Monitors.
- Click + Add New Monitor.
- In the monitor type picker, select Browser.
Step 2: Configure the monitor
| Field | Description |
|---|---|
| URL | The page to load (must be publicly reachable from APIContext nodes) |
| Browser engine | Chromium, Firefox, or WebKit |
| Viewport | Width × height in pixels (default: 1280 × 720) |
| Timeout (ms) | Maximum page-load time before marking as failed |
| Wait for | load, domcontentloaded, or networkidle — when to stop the timer |
Step 3: Add assertions
Use the Assertions tab to define pass/fail criteria:
- HTTP status — must be 2xx (checked before rendering)
- LCP ≤ N ms — Largest Contentful Paint within budget
- CLS ≤ N — Layout shift score within budget (Google recommendation: < 0.1)
- FCP ≤ N ms — First Contentful Paint within budget
- No console errors — fail if the browser logs any errors
Step 4: Add to a schedule
Add the monitor to a schedule. Browser monitors are typically run less frequently than HTTP monitors — every 15–60 minutes is common — because headless browser runs are heavier workloads.
See also