Browser Monitors
Preview
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.
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.