> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devhelm.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Synthetics

> Run packaged Playwright browser journeys and multi-step API checks, then inspect their run history and captured evidence

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

| Type | Use it for |
| - | - |
| Browser | Sign-in, signup, checkout, and other journeys that need a browser |
| Multi-step API | Authenticate, create a resource, read it back, and clean up without opening a browser |

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`.

<Note>
  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.
</Note>

Follow the [package creation workflow](/synthetics/api-checks#upload-and-create-the-monitor). 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](/monitoring/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.

<Note>
  **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.
</Note>

## 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.

<CardGroup cols={2}>
  <Card title="Multi-step API checks" icon="code" href="/synthetics/api-checks">
    Package a request sequence and create its monitor through the API.
  </Card>

  <Card title="API authentication" icon="key" href="/authentication">
    Create a token for the workspace that owns your checks.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.