--- title: "HTTP/HTTPS check | Grafana Cloud documentation" description: "HTTP/HTTPS check HTTP and HTTPS checks are used to test an HTTP/s endpoint, measuring the uptime and response latency. These checks can also be configured for more advanced tests, like if a site is using a specific version of SSL, for SSL certificate expiration, or if HTTP automatically redirects to HTTPS." --- > For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt). # HTTP/HTTPS check HTTP and HTTPS checks are used to test an HTTP/s endpoint, measuring the uptime and response latency. These checks can also be configured for more advanced tests, like if a site is using a specific version of SSL, for SSL certificate expiration, or if HTTP automatically redirects to HTTPS. You can also use [MultiHTTP checks](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/multihttp/) to test multiple URLs in a single check. ## Create an HTTP check You can create and execute an HTTP check from the Synthetic Monitoring UI. 1. On the left-side menu, select **Testing & synthetics** > **Synthetics**. 2. Click **Create new check** or **Add new check**. 3. Choose **API Endpoint** as your check type. 4. Set the values for the required [options](#options). 5. Schedule or run the check. 1. Click **Save** to schedule the check. 2. Click **Test** to run the HTTP check. ## Options The list of common options to all check types: ### Common options 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. | HTTP checks have additional options, which don’t produce any [additional labels in the resulting check metrics](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/#metric-labels). ### HTTP settings Expand table | Option | Description | |-----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------| | Request method | The HTTP method the probe uses. | | Request body | The body of the HTTP request. | | Request headers | The headers to send with the request. | | Compression algorithm | The compression algorithm to expect in the response. | | Proxy URL | The URL of the proxy used to connect to the target. | | Proxy connect headers | Name/value pairs of headers to send to the proxy. | | Publish full set of metrics | Whether to publish additional metrics to create histograms (used for Apdex scores or heatmaps). Default is false to reduce the number of active series. | #### Request headers You can specify custom request headers to be sent to with your check, or override default header values. For example, Synthetic Monitoring sends a default `User-Agent` header in the format: http ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```http User-Agent: synthetic-monitoring-agent/v0.41.3 (linux amd64; 1522bdcd162c24088daf19d0aa6667773e69825a; 2025-09-02T13:45:18Z; +https://github.com/grafana/synthetic-monitoring-agent) ``` You can override that header by: 1. In your HTTP check, Request edit page, click **Request options**. 2. Click **+ Add request header**. 3. Set the name field as “User-Agent”, and the value field as a custom value. 4. Click **Save**. After saving, each test run includes the custom value as the User-Agent field for subsequent runs. #### Compression If you specify a compression algorithm, the body response is *required* to contain a header matching that value, and the body itself must be compressed using that algorithm. The check fails if that’s not the case. ### TLS config Expand table | Option | Description | |---------------------------------------|----------------------------------------------------------| | Disable target certificate validation | Whether to validate the certificate that is presented. | | Server name | The server name used during certificate validation. | | CA certificate | The certificate for the certificate authority. | | Client certificate | The client certificate to present during authentication. | | Client key | The corresponding key for the client certificate. | ### Authentication Expand table | Option | Description | |------------------------------------------------|------------------------------| | Include bearer authorization header in request | Use *bearer authentication*. | | Include basic authorization header in request | Use *basic authentication*. | ### Validation Expand table | Option | Description | |---------------------|---------------------------------------------------------------| | Valid status codes | Status codes considered as valid responses (defaults to 2xx). | | Valid HTTP versions | HTTP versions considered as valid responses. | | SSL options | Whether to require or reject SSL. Defaults to ignore. | | Regex validations | Set of regular expression validations. | For each regular expression validation, you must specify whether to match a header or the body of the response. In either case, you have to specify a regular expression using [Go’s syntax](https://github.com/google/re2/wiki/Syntax). The logic of the match can be inverted; normally, the check will **fail** if the header or body **matches** the provided regular expression, but with **invert match** selected, the check will **fail** if the header or body **does not match** the provided regular expression. For header matches, you can also specify that a missing header doesn’t cause the check to fail. ### Advanced options Expand table | Option | Description | |------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | IP version | The IP version to use: `V4` (IPv4 only), `V6` (IPv6 only), or `Any` (prefers IPv6, falls back to IPv4). With `Any`, if no IPv6 (AAAA) record exists, the check uses IPv4 (A) records. The check doesn’t retry with a different IP version if the initial connection fails. | | Follow redirects | Whether to follow redirects or to stop at the first response. | | Cache busting query parameter name | The *name* of the parameter appended to the URL to prevent caching. | ## Metrics Checks store their results as Prometheus metrics, including the list of common metrics: 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. | Additionally, HTTP checks produce the following metrics: Expand table | Metric | Description | |-------------------------------------------------|----------------------------------------------------------------------------------------| | `probe_dns_lookup_all_time_seconds` | Returns the time taken for probe DNS lookup in seconds (histogram). | | `probe_dns_lookup_time_seconds` | Returns the time taken for probe DNS lookup in seconds. | | `probe_failed_due_to_regex` | Indicates if probe failed due to regular expression. | | `probe_http_all_duration_seconds` | Duration of HTTP request by phase, summed over all redirects (histogram). | | `probe_http_content_length` | Length of HTTP content response. | | `probe_http_duration_seconds` | Duration of HTTP request by phase, summed over all redirects. | | `probe_http_redirects` | The number of redirects. | | `probe_http_ssl` | Indicates if SSL was used for the final redirect. | | `probe_http_status_code` | Response HTTP status code. | | `probe_http_uncompressed_body_length` | Length of uncompressed response body. | | `probe_http_version` | Returns the version of HTTP of the probe response. | | `probe_ip_addr_hash` | Specifies the hash of the IP address. It’s useful to detect if the IP address changes. | | `probe_ip_protocol` | Specifies whether probe IP protocol is IPv4 or IPv6. | | `probe_ssl_earliest_cert_expiry` | Returns last SSL chain expiry in Unix time. | | `probe_ssl_last_chain_expiry_timestamp_seconds` | Returns last SSL chain expiry in timestamp. | | `probe_ssl_last_chain_info` | Contains SSL leaf certificate information. | | `probe_tls_version_info` | Returns the TLS version used or NaN when unknown. | ## Limitations The request body size for HTTP and HTTPS checks is limited to 64KB. Checks that exceed this limitation return the error message “Something went wrong running the check, unexpected EOF.”