---
title: "Check types | Grafana Cloud documentation"
description: "Check types A Synthetic Monitoring check is a scheduled test of a target. The check is the configuration, not a single run: it defines what to test, what counts as success, how often to test, and which public or private probes run the test. The job name and target together uniquely identify a check. A check execution is one run of a check from one probe, so one check produces many executions over time."
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

# Check types

A Synthetic Monitoring check is a scheduled test of a target. The check is the configuration, not a single run: it defines what to test, what counts as success, how often to test, and which [public](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/public-probes/) or [private](/docs/grafana-cloud/testing/synthetic-monitoring/set-up/set-up-private-probes/) probes run the test. The job name and target together uniquely identify a check. A check execution is one run of a check from one probe, so one check produces many executions over time.

Each check execution saves its results as Prometheus metrics and Loki logs, which you can use to [configure Grafana alerts](/docs/grafana-cloud/testing/synthetic-monitoring/configure-alerts/) for custom notifications and incident management.

Synthetic Monitoring provides check types for endpoints, network paths, multi-step API workflows, scripts, and browser journeys.

Check dashboards report uptime and reachability. Uptime measures whether at least one probe succeeded in each reported time point; reachability measures the percentage of successful probe executions. For the calculations and a worked example, refer to [Uptime and reachability](/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/analyze-results/uptime-and-reachability/).

Give it a try using Grafana Play

With Grafana Play, you can explore and see how it works, learning from practical examples to accelerate your development. This feature can be seen on [Synthetic Monitoring Checks](https://play.grafana.org/a/grafana-synthetic-monitoring-app/home).

[Try it](https://play.grafana.org/a/grafana-synthetic-monitoring-app/home)

## Choose a check type

The Synthetics app groups check types into four options on the **Choose a check type** page: **API Endpoint**, **Multi Step**, **Scripted**, and **Browser**.

Choose the simplest check type that verifies the outcome you care about. Use separate **API Endpoint** checks for independent targets. Use **Multi Step**, **Scripted**, or **Browser** when the requests or interactions form a single ordered journey.

Use the following table to choose a check type and find the option that creates it.

Expand table

| What you want to monitor                                                                            | Check type                                                                                      | Select in the app                                     |
|-----------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|-------------------------------------------------------|
| Whether a host is reachable, and its response latency from each probe location                      | [Ping](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/ping/)             | **API Endpoint** with the **Ping** request type       |
| A single HTTP endpoint, including its response, TLS version, certificate expiration, and redirects  | [HTTP](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/http/)             | **API Endpoint** with the **HTTP** request type       |
| Whether a DNS server returns the expected record for a name, such as an A record for `example.org`  | [DNS](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/dns/)               | **API Endpoint** with the **DNS** request type        |
| Whether a service accepts TCP connections, for example, a mail server, FTP server, or message queue | [TCP](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/tcp/)               | **API Endpoint** with the **TCP** request type        |
| The network path to a target, and how that path changes over time                                   | [Traceroute](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/traceroute/) | **API Endpoint** with the **Traceroute** request type |
| An ordered HTTP journey where requests share response data or session state                         | [MultiHTTP](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/multihttp/)   | **Multi Step**                                        |
| A flow that needs custom logic, JavaScript libraries, or WebSocket services                         | [k6 scripted](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/k6/)        | **Scripted**                                          |
| A user journey in a real browser, including page interactions and Web Vitals metrics                | [k6 browser](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/k6-browser/) | **Browser**                                           |

If more than one check type can verify what you care about, consider check frequency before you choose. Scripted and browser checks run at most once every 60 seconds, and traceroute checks at most once every 120 seconds, while the other check types run at most once every 10 seconds.

Browser test executions are billed separately from API test executions. The number of probes, execution duration, and check frequency also affect usage. For details, refer to [Synthetic Monitoring pricing](/docs/grafana-cloud/platform/pricing-and-usage/synthetic-monitoring/).

### Monitor an endpoint that requires authentication

Which check type you need depends on how your endpoint authenticates requests:

- **The endpoint uses basic authentication, bearer authentication, or a client certificate.** Use an HTTP check. HTTP checks can use managed secrets for basic authentication passwords, bearer tokens, CA certificates, client certificates, and client keys. Refer to [HTTP check authentication](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/http/#authentication).
- **The endpoint uses a sensitive credential in a custom request header.** Use a k6 scripted check to read the credential from a managed secret and add it to the request. HTTP checks support custom request headers, but can’t read their values from managed secrets.
- **Signing in is a request that returns a token or establishes a session cookie.** Use a MultiHTTP check. MultiHTTP preserves cookies between requests. To reuse a token, capture it from the response with a [variable](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/multihttp/#variables) and send it with later requests. Use a k6 scripted check if the flow needs logic that assertions and variables can’t express.
- **Signing in means filling in a form in a web page.** Use a k6 browser check. A browser check is the only check type that runs a real browser, so it’s the only one that can fill in a sign-in form, wait for the page that loads next, and continue as a signed-in user. For a worked example, refer to [Create a k6 browser check](/docs/grafana-cloud/testing/synthetic-monitoring/get-started/create-a-k6-browser-check/).

HTTP, scripted, and browser checks can read supported values from [secrets](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/manage-secrets/).

## How checks run across probes

Every probe you select for a check runs that check independently at every interval. Probes don’t rotate between intervals, so if you select three probes and run a check every minute, the check executes three times per minute, once from each probe.

Each probe run counts as a separate execution for billing, and runs from different locations arrive at your target concurrently.

For details, refer to [How probes run checks](/docs/grafana-cloud/testing/synthetic-monitoring/introduction/#how-probes-run-checks).

## The check form

You configure every check type with the same five-step form. The form uses a consistent step order, but the available options vary by check type.

Expand table

| Step | Name                                     | What you configure                                                                                              |
|------|------------------------------------------|-----------------------------------------------------------------------------------------------------------------|
| 1    | **Request**, **Requests**, or **Script** | The check’s identity and what to test, including the job name, the target, and the folder to store the check in |
| 2    | **Uptime**                               | What counts as a successful execution, and the check timeout                                                    |
| 3    | **Labels**                               | Custom labels and cost attribution labels                                                                       |
| 4    | **Execution**                            | The probe locations to run the check from, and how often it runs                                                |
| 5    | **Alerting**                             | Per-check alerts for this check                                                                                 |

The first step is named **Request** for API Endpoint checks, **Requests** for Multi Step checks, and **Script** for Scripted and Browser checks. This step contains the fields for describing the request or writing the script. For API Endpoint checks, it also contains the **Request type** field, where you choose between HTTP, Ping, DNS, TCP, and Traceroute. Steps 2 through 5 have the same names for every check type.

The **Labels** step supports two uses of labels:

- [Custom labels](/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/analyze-results/custom-labels/) help you organize checks, query metrics and logs, and route alerts by attributes such as team or environment.
- [Cost attribution labels](/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/manage-labels/) group check execution costs by attributes such as team or environment in the Cost Management and Billing app.

Choose labels according to whether you need to query check results or attribute execution costs. For how an existing custom label can also serve as a cost attribution label, refer to [Manage labels and cost attribution](/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/manage-labels/).

The form indicates your current step. To move between steps, select a step or use the button labeled with the name of the next step.

**Save** stores the check and starts running it. It’s available from every step, so you don’t have to reach step 5 to save a check. The tabs next to the form provide additional actions:

- **Test** runs the check once without saving.
- **Secrets** selects the [secrets](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/manage-secrets/) the check can use. It appears for HTTP, Scripted, and Browser checks.
- **Terraform** displays the check as Terraform configuration.
- **Docs** links to reference documentation.

## Check type identifiers

Each check type has an identifier that the REST API, Terraform, check metrics, and the **Checks** list use:

Expand table

| Check type  | Identifier   |
|-------------|--------------|
| HTTP        | `http`       |
| Ping        | `ping`       |
| DNS         | `dns`        |
| TCP         | `tcp`        |
| Traceroute  | `traceroute` |
| MultiHTTP   | `multihttp`  |
| k6 scripted | `scripted`   |
| k6 browser  | `browser`    |

The **Checks** list displays the identifier as each check’s type. The REST API uses it as the key under `settings`; Terraform uses it as the block name inside `settings` in a `grafana_synthetic_monitoring_check` resource; and check metrics use it as the value of the `check_name` label.

## Common options

Each check type has specific options. **Enabled**, **Job name**, **Target**, **Probe locations**, and **Custom labels** are the same on every check type. The frequency and timeout ranges in this table apply to DNS, HTTP, MultiHTTP, Ping, and TCP checks. For k6 and traceroute values, refer to [k6 scripted checks](/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/create-checks/checks/k6/), [k6 browser checks](/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/create-checks/checks/k6-browser/), and [traceroute checks](/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/create-checks/checks/traceroute/).

Expand table

| Option          | Description                                                                                                                                                                             |
|-----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Enabled         | Whether the check is enabled or not.                                                                                                                                                    |
| Job name        | Refer to the check name. Check metrics include a `job` label with the value of this option.                                                                                             |
| Target          | Target of the check request. Check metrics include an `instance` label with the value of this option.                                                                                   |
| Probe locations | The locations where the check should run from. Check metrics include a `probe` label with the value of the probe location running the check.                                            |
| Frequency       | The frequency the check should run in seconds. The value can range from 10 to 3600 seconds. Only the `sm_check_info` metric includes the `frequency` label.                             |
| Timeout         | Maximum execution time for the check. The value can range from 1 to 60 seconds.                                                                                                         |
| Custom labels   | (Optional) Custom labels applied to check metrics. Refer to [Custom labels](/docs/grafana-cloud/testing/synthetic-monitoring/analyze-results/custom-labels/) for querying instructions. |

## Common check metrics

Checks collect the results of the execution and save them as Prometheus metrics.

Each check type produces specific Prometheus metrics with their results. To identify the check type in a query, use the `check_name` label on `sm_check_info`, whose values are the [check type identifiers](#check-type-identifiers). The following is a list of metrics common to all check types.

Expand table

| Metric                       | Description                                                         |
|------------------------------|---------------------------------------------------------------------|
| `probe_all_duration_seconds` | Returns how long the probe took to complete in seconds (histogram). |
| `probe_duration_seconds`     | Returns how long the probe took to complete in seconds.             |
| `probe_all_success`          | Displays whether or not the probe was a success (summary).          |
| `probe_success`              | Displays whether or not the probe was a success.                    |
| `sm_check_info`              | Provides information about a single check configuration.            |

For the list of additional metrics, refer to the metrics documentation for each check type: [DNS metrics](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/dns/#metrics), [HTTP metrics](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/http/#metrics), [k6 browser metrics](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/k6-browser/#metrics), [k6 scripted metrics](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/k6/#metrics), [MultiHTTP metrics](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/multihttp/#metrics), [Ping metrics](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/ping/#metrics), [TCP metrics](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/tcp/#metrics), and [Traceroute metrics](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/traceroute/#metrics).

### Metric labels

In Prometheus, labels add additional context to the metrics, and can be used for querying and visualizations.

All check metrics include the system labels `config_version`, `instance`, `job`, and `probe`. Some check options and metric types add labels to provide additional information.

Expand table

| Option          | Label                                                                                                                                                                           | Metrics           |
|-----------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------|
| Check revision  | Include a `config_version` label with the synthetic check configuration revision.                                                                                               | All metrics       |
| Job name        | Include a `job` label with the value of this option.                                                                                                                            | All metrics       |
| Target          | Include an `instance` label with the value of this option.                                                                                                                      | All metrics       |
| Probe locations | Include a `probe` label with the value of the probe location running the check.                                                                                                 | All check metrics |
| Frequency       | Include a `frequency` label with the value of this option.                                                                                                                      | `sm_check_info`   |
| Custom labels   | (Optional) Include up to 10 custom labels. Refer to [Custom labels](/docs/grafana-cloud/testing/synthetic-monitoring/analyze-results/custom-labels/) for querying instructions. | All check metrics |

The `sm_check_info` metric also includes static metadata labels such as `check_name` and `geohash`. For the complete reference of the labels that Synthetic Monitoring applies to metrics and logs, refer to [System labels](/docs/grafana-cloud/testing/synthetic-monitoring/system-labels/).

Custom label names can’t collide with the reserved system label names: the API rejects checks that use a reserved name as a custom label. For details, refer to [System labels](/docs/grafana-cloud/testing/synthetic-monitoring/system-labels/).

Note that each unique metric name and label set creates a new time series.