Multi-step API transactions and browser checks

API transactions

A transaction monitor runs up to 10 HTTP requests in order. Each step can assert the status code, a keyword, response headers and JSON paths, and can extract values from the JSON body or a header into variables. Later steps reuse them with {{name}} in the URL path, headers or body. The flow stops at the first failing step; the incident names that step.

• Scheme and host of every step must be literal so destinations are validated when you save. Placeholders are allowed in paths, query strings, headers and bodies.
• Steps using POST, PUT, PATCH or DELETE require acknowledging that the request repeats on every check. Use a dedicated test account.
• Stored credentials (basic, bearer or a custom header) apply only to steps marked useAuth: true and are stripped automatically if a redirect leaves the origin.
• The whole flow is bounded by the monitor timeout; each step by its own timeout. Bodies are read up to 128 KiB and never stored, except a 2 KiB snippet of the failing step when you opt in.

Availability for a transaction monitor means the whole flow succeeded. Latency is the total duration of all steps.

Browser checks

A browser check loads your page in headless Chromium on a probe that runs a separate browser pool, then executes scripted steps: goto, click, fill, wait_for, assert_text, assert_url and assert_element. You cannot run custom JavaScript inside the page, by design. What is recorded: navigation timing (time to first byte, DOM content loaded, load event), Largest Contentful Paint and Cumulative Layout Shift as lab values, console errors, failed sub-resource requests, the number of requests, the final URL and page title, and optionally a JPEG screenshot (at most 150 KiB, kept 7 days). Outcome rules: a failing step, a navigation returning 4xx/5xx, or (when enabled) JavaScript or resource errors mark the check DOWN; a load slower than the configured threshold marks it DEGRADED.

Safety boundaries of browser checks

• Chromium runs with its own sandbox enabled, as an unprivileged user. Production probes refuse to start browser checks as root or with the sandbox disabled; those modes exist only for local test containers.
• Chromium never connects to the network directly: it is forced through an egress proxy inside the probe process, loopback included. The proxy applies the same destination policy as HTTP monitors (schemes, standard ports, blocked private, loopback, link-local and metadata ranges), resolves names itself and pins the validated address, so DNS rebinding cannot swap the destination after validation. Each redirect hop, iframe, popup, fetch and WebSocket handshake is a separate decision.
• Request interception inside the browser remains as an independent second check and enforces the per-run request limit.
• Capabilities without a validated path are disabled rather than left open: QUIC, non-proxied WebRTC UDP, service workers, ws:// and wss:// WebSockets, downloads, popups and browser permissions. The control plane hostname is refused even though it is public.
• Each run uses a fresh browser context, is limited to 90 seconds, 300 requests and one page, relays at most 20 MiB per connection, and the browser process is recycled after 50 runs. Memory and process limits of the container are the deployment's responsibility (the probe image ships a non-root user; apply cgroup limits in the orchestrator).
• Evidence never carries secrets: URLs in failed-request lists, final URLs and error messages are stripped of query strings, fragments and credentials; filled form values are not recorded; the probe logs counters only. Screenshots (at most 150 KiB) are stored per workspace, served only to members of that workspace, and deleted after seven days. No traces or HAR files are produced.
• Browser probes should additionally be deployed in a network segment without routes to internal infrastructure; the controls above are tested with local fixtures (private, loopback, metadata and rebinding destinations, redirects, iframes, popups, WebSockets, service workers, WebRTC) in apps/probe/test.
• Public browser execution stays disabled: plans include no browser allowance and the add-on is not purchasable until the cost model is approved.

Cost model and allowances

Browser executions consume far more CPU and memory than HTTP probes, so they are metered per account and calendar month. The minimum interval is 5 minutes (about 8,800 runs per month for one monitor). Plans include no browser allowance until the Browser Synthetics add-on is priced; contract allowances can be granted by operators. When the allowance is exhausted the scheduler records a gap instead of running the check, and the monitor page says so.

What these checks are not

Lab timings from a probe are not real-user performance. For field data see Real User Monitoring. A passing browser flow proves that the scripted path worked from the probe location at that moment; it does not certify accessibility, SEO or correctness of every page.