Documentation for automated readers
A curated documentation index is available at: https://grafana.com/llms.txt
A complete documentation index is available at: https://grafana.com/llms-full.txt
These indexes can help with page discovery before fetching individual documents.
This page is also available in Markdown, which may be easier for automated readers and AI tools to parse than HTML. The Markdown version is available at https://grafana.com/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/multihttp.md, or by sending Accept: text/markdown to https://grafana.com/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/multihttp/. For broader documentation discovery, the curated index is available at https://grafana.com/llms.txt and the complete index is available at https://grafana.com/llms-full.txt.
MultiHTTP check
MultiHTTP checks can test multiple URLs in a single check while measuring uptime and response latency like other check types. You can also use the results of one request in a later one and make several assertions for each request.
Note
MultiHTTP requests don’t automatically validate against a 200 HTTP status code. To ensure failed requests affect uptime and reachability calculations, you must define assertions for each request in the Define uptime step when creating or editing a check.
Note
MultiHTTP test executions make outbound connections to
jslib.k6.iowhen run. If you run MultiHTTP checks on private probes behind a firewall, adjust your firewall rules to allow connections tojslib.k6.io.
Options
The list of common options to all check types:
| 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 for querying instructions. |
Additionally, MultiHTTP checks have the following options:
| Option | Description |
|---|---|
| Request target | The URL to send a request to. |
| Request method | The HTTP method to use when sending the request. |
| Headers | Name and value of HTTP headers to add to the request. |
| Query parameters | Name and value of URL query parameters. |
| Assertions | See below. |
| Variables | See below. |
These last options don’t produce any additional labels in the resulting check metrics.
Assertions
There are four types of assertions.
Text assertions
Text assertions match a string against different parts of a response:
- Body: Match a string against the entire response body.
- Headers: Each individual header is matched against the specified value. The header name is lower-cased, followed by a colon and a space (
:), followed by the header’s value (as is). The match succeeds if at least one of the headers matches. - Status code: Match a string against the HTTP status code.
The match can be performed against the specified subject in one of several ways:
- Contains: The specified value must be present somewhere in the subject.
- Does not contain: The specified value must not be present anywhere in the subject.
- Equals: The subject must be exactly equal to the specified value.
- Starts with: The subject must start with the specified value.
- Ends with: The subject must end with the specified value.
JSON path value assertions
This type of assertion expects the response body to be a JSON document, and it accepts a JSONPath expression to be matched against the specified value. The possible matches are:
- Contains: The specified value must be present somewhere in the result of evaluating the JSONPath expression.
- Does not contain: The specified value must not be present anywhere in the result of evaluating the JSONPath expression.
- Equals: The result of evaluating the JSONPath expression must be exactly equal to the specified value.
- Starts with: The result of evaluating the JSONPath expression must start with the specified value.
- Ends with: The result of evaluating the JSONPath expression must end with the specified value.
JSON path assertions
This type of assertion expects the response body to be a JSON document, and it accepts a JSONPath expression that must evaluate to a non-empty result for the assertion to succeed.
Regex assertions
Regular expression assertions evaluate the provided regular expresion against one of various subjects:
- Body: The entire response body is used.
- Headers: Each individual header is evaluated against the specified regular expression. The header name is lower-cased, followed by a colon and a space (
:), followed by the header’s value (as is). The match succeeds if at least one of the headers matches. - Status code: The status code is used.
Variables
Variables can capture values from the responses to individual HTTP requests. Each variable must be named, and the name must be unique across all requests. The name can be used in subsequent requests by using the ${name} variable. It’s possible to use this anywhere where a string is expected, for example, as the value of a header or the value of an assertion.
Variable values can be obtained from the following.
- A JSONPath: The value of the variable is the result of evaluating the JSONPath expression.
- A regular expression: The value of the variable is the string matching the regular expression.
- A CSS selector: The value of the variable is the value of evaluating the CSS selector against the response body. Optionally, an attribute name can be specified, in which case the value of the variable is the value of the specified attribute.
Metrics
Checks store their results as Prometheus metrics, including the list of common metrics:
| 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. |
Additionally, MultiHTTP checks produce the following metrics:
| Metric | Additional labels | Description |
|---|---|---|
probe_check_success_rate | check, method, scenario, url | The pass/fail rate of request assertions. The check label identifies the assertion by name. |
probe_checks_total | check, method, result, scenario, url | The number of passing and failing request assertions. The result label can have a value of pass or fail. |
probe_data_received_bytes | scenario | The total number of bytes received for the whole check. |
probe_data_sent_bytes | scenario | The total number of bytes sent for the whole check. |
probe_http_all_duration_seconds | method, name, phase, proto, scenario, status, tls_version, url | Histogram of HTTP request duration by phase. |
probe_http_duration_seconds | method, name, phase, proto, scenario, status, tls_version, url | For each method and URL group, the request duration in seconds, split by phase. |
probe_http_error_code | method, name, proto, scenario, status, tls_version, url | The k6 error code associated with the request, when present. |
probe_http_got_expected_response | method, name, proto, scenario, status, tls_version, url | Indicates whether the response matched the expected response status criteria. |
probe_http_info | method, name, proto, scenario, status, tls_version, url | Information about the response. It always returns a value of 1. |
probe_http_requests_failed | method, name, proto, scenario, status, tls_version, url | Indicates whether the individual request failed. |
probe_http_requests_failed_total | method, name, proto, scenario, status, tls_version, url | The number of failed requests by method and URL. |
probe_http_requests_total | method, name, proto, scenario, status, tls_version, url | The total number of requests by method and URL. |
probe_http_ssl | method, name, proto, scenario, status, tls_version, url | Indicates whether TLS was used for the request, for each method and URL group. |
probe_http_status_code | method, name, proto, scenario, status, tls_version, url | For each method and URL group, the response code for the request. |
probe_http_total_all_duration_seconds | method, name, proto, scenario, status, tls_version, url | Histogram of total HTTP request duration. |
probe_http_total_duration_seconds | method, name, proto, scenario, status, tls_version, url | For each method and URL group, the total request duration in seconds. |
probe_http_version | method, name, proto, scenario, status, tls_version, url | For each method and URL group, the version of the HTTP protocol used to complete the request. |
probe_iteration_all_duration_seconds | scenario | Histogram of the k6-reported MultiHTTP iteration duration. |
probe_iteration_duration_seconds | scenario | The k6-reported MultiHTTP iteration duration in seconds. |
probe_script_all_duration_seconds | None | Histogram of the k6-reported MultiHTTP script execution time. |
probe_script_duration_seconds | None | The k6-reported MultiHTTP script execution time in seconds. |
Was this page helpful?
Related resources from Grafana Labs


