New Relic Synthetics: When a Scripted Browser Monitor Beats an API Test

The decision: what are you actually trying to prove?

New Relic Synthetics offers several monitor types. Two of them cover most "is this journey working?" questions: Scripted Browser, which drives a real browser, and API Test, which makes HTTP requests and asserts on the response.

The useful question is not which type is better, but which one can fail for the reason you care about. If the failure you fear is "the page renders but the button does nothing," only a browser monitor can see it. If the failure you fear is "the service returns 500 or takes four seconds," an API test catches it faster and with far less noise.

Constraints that narrow the choice before you write any script

• Where the target lives. Public endpoints can be checked from New Relic's public locations. Anything behind a firewall — internal admin tools, pre-production hosts, services on private DNS — needs a private location, which means running Synthetics job managers inside your network. Both monitor types can use private locations, so this is a shared prerequisite rather than a differentiator.
• Who can create it. Monitor creation is governed by your New Relic role and its capabilities. If the "add monitor" flow is unavailable to you, the problem is permissions, not monitor type. Check your assigned role before designing anything.
• How long the journey takes. Each monitor has a configurable script timeout, and the ceiling differs by monitor type and runtime version. Confirm the current default and maximum in the monitor's own settings in your account rather than trusting a number from a blog post. If a flow genuinely needs longer than the ceiling, split it into two monitors that each assert one stage.
• Run frequency and budget. Synthetics is billed per check execution, and a browser monitor starts a full browser process per run. A high-frequency browser check across several locations adds cost faster than the equivalent HTTP check. Verify the rates that apply to your contract.

Comparison at the level that affects the decision

Dimension	Scripted Browser	API Test
What executes per run	A full browser session	One or more HTTP requests
What you can assert on	DOM presence and visibility, navigation, client-side rendering, screenshots	Status codes, headers, response body, request/response timings
What it cannot see	Nothing about the UI — but it is blind to backend contract drift that never surfaces in the page	JavaScript errors, broken layouts, elements that render but do not respond
Typical flakiness source	Timing, rendering delays, DOM changes, third-party assets	Network variability, auth token expiry, redirect handling
Redirects	Followed by the browser as part of navigation	Depends on the HTTP client's configuration — test it explicitly if your assertion depends on a redirect chain
Relative compute per run	Higher	Lower
Best fit	Login, checkout, form submission, anything where a visual or interactive regression matters	Endpoint health, payload contracts, latency budgets, high-frequency checks

Trade-offs worth naming explicitly

Scripted Browser buys realism at the cost of stability. You get a genuine user's view, including client-side rendering and visual evidence. You also inherit every source of timing variance in the page, which is why browser monitors are the ones most likely to produce a false alarm at 3 a.m.

API Test buys determinism at the cost of coverage. A well-written API test is close to binary: the endpoint answered correctly or it did not. That makes it a good fit for alerting and a poor fit for catching a regression that only exists in the browser.

The mistake to avoid is treating them as alternatives. They answer different questions and are usually worth running side by side on the same journey.

A concrete split: the checkout journey

Suppose the journey is sign in, add an item to the cart, and reach an order confirmation page. Rather than one long browser script, split the responsibility:

• API Test — exercises the cart and order endpoints with a test account, asserting the response status and that the returned cart total matches the expected value. Run it frequently from several locations. This owns contract and latency.
• Scripted Browser — signs in, adds an item, reaches the confirmation page, asserts the confirmation element is present and displayed, and captures a screenshot. Run it less frequently. This owns rendering and interaction.

Keep the alerts separate. A browser monitor that fails on a slow third-party font should not page the backend on-call engineer.

The skeleton below shows the shape of a browser script. It is deliberately incomplete: helper names and options have changed across Synthetics runtime versions, so confirm them against the New Relic documentation for the runtime you select before relying on any of it.

// Illustrative shape only — not a verified runnable script.
// Confirm exact helper names and options for your runtime version.

$browser.get('https://shop.example.com/login');

// Locate the credential fields, send the test values, submit the form.
// Then wait for the confirmation element and assert it is displayed.
// Capture a screenshot artifact so a failure has visual evidence.

For the API side, the equivalent script asserts on status code and parses the body to check a field. Whether your HTTP client follows redirects by default is a configuration detail worth testing rather than assuming — if your assertion depends on a redirect chain, write a check that proves the behavior in your account.

Validating a monitor before you trust it

1. Create the monitor in the Synthetics UI, selecting the type, runtime, locations, and script timeout. Replace every placeholder hostname and selector with your own values.
2. Use Run now and read the execution log. For a browser monitor, confirm the screenshot artifact is attached to the run. For an API test, confirm the status code and any timing breakdown appear in the result details.
3. Deliberately break it: point the browser monitor at a selector that does not exist, or change the API test's expected field value. Re-run and confirm the monitor reports a failure. A monitor that passes everything has not been validated.
4. Restore the correct values and re-run.
5. Optionally, retrieve the monitor definition through the NerdGraph API and diff the returned script against your source of truth. The Synthetics schema is versioned, so confirm field names in the API explorer for your account rather than copying a query from elsewhere.

Limitations and what to re-check

This guide describes the decision shape, not a verified implementation. Several details are version- and contract-dependent and should be confirmed in your own account: the default and maximum script timeout per monitor type, the exact scripting helper names in the runtime you select, whether your HTTP client follows redirects by default, and the per-execution billing that applies to you.

If you need a runnable script, start from the current New Relic documentation and the in-product script editor rather than from a third-party example, including this one.