Skip to main content
Use Synthetics to check a complete browser journey or a sequence of API requests. A monitor runs a packaged Playwright test on a schedule, in the regions you select. Open its run history in the dashboard to investigate failures.

​
Choose a check type

A browser check uses the BROWSER monitor type. A multi-step API check uses MULTI_STEP_API. Your test code contains the assertions; these monitor types do not use the assertion editor for HTTP uptime monitors.

​
Prepare the test package

Keep the test and the local files it imports together in a ZIP. Choose the entrypoint by its relative path inside the archive, such as tests/checkout.spec.ts. Record the SHA-256 digest of the ZIP and the list of included files. Keep credentials out of the package. Associate the monitor with an environment, declare the secret names the test requires, and configure their bindings. The test reads its runtime variables through process.env.
Package creation currently uses the API. The dashboard provides monitor settings, bindings, revisions, and run evidence; it does not provide a ZIP upload wizard. The published CLI does not expose a Synthetics package upload command.
Follow the package creation workflow. Browser checks use the same workflow with type set to BROWSER and a browser test entrypoint.

​
Configure the schedule

Set the check frequency and selected regions when creating the monitor. You can inspect and change the schedule in the monitor’s settings. Available regions and minimum intervals depend on your deployment and plan; see probe regions and the workspace’s current limits. Each selected region performs its own run. Increasing the number of regions or shortening the interval increases run usage. Browser and API checks use separate run allowances.

​
Read a failed run

Open Synthetics, select the monitor, and open a run from its history. The run identifies its region, outcome, duration, and revision. Use the steps and evidence views to inspect the failure. Browser evidence can include screenshots, video, a trace, network requests, console output, and runner logs. What is available depends on what the run captured and whether the artifact is still retained. The viewer distinguishes available, missing, and expired artifacts. An API check reports its test outcome and recorded evidence. It does not produce browser screenshots or video. Put meaningful assertions and cleanup in the test so a failure identifies the request or condition that broke.
Run now starts an actual run and consumes usage. The uptime monitor’s synchronous Test action is not available for Browser or Multi-step API monitors.

​
Keep revisions reproducible

A package revision records its digest, entrypoint, and file list. Optional Git metadata records which commit produced it. Runs retain their revision reference, so you can compare failures without assuming they used the latest uploaded files.

Multi-step API checks

Package a request sequence and create its monitor through the API.

API authentication

Create a token for the workspace that owns your checks.