Browser Monitors

Availability

Browser monitors are available in organization projects. In other projects, the Monitors page has no Add Browser Test button; contact support to turn browser monitors on.

A Browser Monitor loads your page in a real headless browser instead of a plain HTTP client. This captures what a user would see: how long the page takes to render, how each resource loads, and what errors appear in the console. For an overview of browser monitoring capabilities including visual regression detection and HAR capture, see Website 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 paint timings (FCP and LCP) and time to first byte for measuring against a performance budget
• Verify that JavaScript-rendered content appears correctly
• Detect console errors or failed sub-resource loads that HTTP monitors miss

Metrics captured

Metric	Full name	What it measures
FP	First Paint	Time until the browser first renders anything
FCP	First Contentful Paint	Time until the first text or image renders
LCP	Largest Contentful Paint	Time until the largest visible element renders
TTFB	Time to First Byte	Server response time before content begins
Page load	Page load time	Total time to load the page
Resource timings	Resource Timing entries	Timing, status, and size of each request the page makes

Each result also records console messages and failed requests. Interaction to Next Paint (INP), Cumulative Layout Shift (CLS), and First Input Delay (FID) are not collected.

Setup

Step 1: Create a browser monitor

1. In the sidebar, under Configure Monitoring, click Monitors.
2. Click Add Browser Test.
3. In the Create Browser Test panel, enter the URL to load and a Name.
4. Click Create and Edit to create the monitor and open it, so you can configure it in the next step. Create Monitor creates it without opening it.

Step 2: Configure the monitor

On the monitor's Edit tab, under Browser Test Configuration:

Field	Description
Name	The name of the monitor
URL	The page to load (must be publicly reachable from APIContext nodes)

On the monitor's Advanced tab:

Field	Description
User Agent	A custom user agent string. Leave it blank to use the browser's own user agent.
Maximum timeout	The longest the run may take, in seconds, before the result is a connection error. The limit is 120 seconds, and a run never gets more than half the interval of the schedule it runs on.

Step 3: Set conditions

Under Conditions on the Edit tab, HTTP Status Code conditions apply to the main page load. These checks are always made:

• 200 to 299: Passed
• 400 to 499: Warning
• 500 or higher: Error

Click Add Condition... to add your own status code conditions.

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.

What the monitor sends

A monitor makes the requests you configure and nothing else: it does not fuzz inputs, scan for other endpoints, or try requests you did not set up. If Retry on failure is on, a retry repeats the same request. What each kind of monitor sends besides your own settings:

API monitors, including API monitors run as workflow steps, send one request to the URL you give, with these additions:

• User-Agent: APImetrics/<version> followed by the HTTP library versions, when the monitor sets no User-Agent of its own. The versions change, so match the APImetrics/ prefix.
• traceparent: a W3C Trace Context header, when the monitor sets none.
• X-APIContext-Agent: true: when Use APIContext Standard Headers is on, on the monitor's Advanced tab. It is on for new monitors.
• Cookie: in a workflow, the cookies that earlier steps sent and received, unless the step sets its own Cookie header.
• Standard HTTP headers the client adds: Host, Accept: */* when no Accept header is set, and Content-Length when there is a body. New monitors start with an Accept: application/json header, which you can change.

New monitors do not follow redirects. If you turn on Follow redirects, the monitor also requests the address a redirect points to, as a browser would.

Browser monitors open the page in a real browser, so the browser also requests whatever the page loads (scripts, images, and the API calls the page makes), as a visitor's browser would. When Use APIContext Standard Headers is on, those requests carry X-APIContext-Agent: true.

MCP monitors open an MCP session with your server, then run only the steps you configure, such as listing tools or calling a tool. A tool call runs that tool with the arguments you set, so choose tools that are safe to run on a schedule. Requests carry a User-Agent that begins APImetrics-MCP/ unless the monitor sets its own, and a traceparent header when none is set.

To allow monitor traffic through a firewall or bot manager, see Identify and allow-list APIContext monitor traffic.

See also

• Core Web Vitals reference (web.dev)
• Set conditions on a monitor
• Schedule monitors