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

On the left-side menu, select Testing & synthetics > Synthetics.
Click Create new check or Add new check.
Choose API Endpoint as your check type.
Set the values for the required options.
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

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.

HTTP checks have additional options, which don’t produce any additional labels in the resulting check metrics.

HTTP settings

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:

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:

In your HTTP check, Request edit page, click Request options.
Click + Add request header.
Set the name field as “User-Agent”, and the value field as a custom value.
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

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

Option	Description
Include bearer authorization header in request	Use bearer authentication.
Include basic authorization header in request	Use basic authentication.

Validation

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

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:

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:

Metric	Additional labels	Description
`probe_dns_lookup_all_time_seconds`	None	Histogram of the DNS lookup duration.
`probe_dns_lookup_time_seconds`	None	Returns the time taken for the DNS lookup in seconds.
`probe_failed_due_to_regex`	None	Indicates if the probe failed due to a regular expression validation.
`probe_http_all_duration_seconds`	`phase`	Histogram of HTTP request duration by phase, summed over redirects.
`probe_http_content_length`	None	Length of the HTTP response body in bytes.
`probe_http_duration_seconds`	`phase`	Duration of the HTTP request by phase, summed over redirects.
`probe_http_last_modified_timestamp_seconds`	None	Value of the `Last-Modified` response header as a Unix timestamp when present.
`probe_http_redirects`	None	The number of redirects followed by the probe.
`probe_http_ssl`	None	Indicates whether TLS was used for the final redirect target.
`probe_http_status_code`	None	Response HTTP status code.
`probe_http_uncompressed_body_length`	None	Length of the uncompressed response body.
`probe_http_version`	None	Returns the HTTP version of the probe response.
`probe_ip_addr_hash`	None	Specifies the hash of the IP address. It’s useful to detect if the IP address changes.
`probe_ip_protocol`	None	Specifies whether the probe IP protocol is IPv4 or IPv6.
`probe_ssl_earliest_cert_expiry`	None	Returns the earliest certificate expiry in the observed TLS chain as Unix time.
`probe_ssl_last_chain_expiry_timestamp_seconds`	None	Returns the final certificate chain expiry as a Unix timestamp.
`probe_ssl_last_chain_info`	`fingerprint_sha256`, `issuer`, `serialnumber`, `subject`, `subjectalternative`	TLS leaf certificate metadata for the last observed chain.
`probe_tls_cipher_info`	`cipher`	Returns the TLS cipher suite used for the connection.
`probe_tls_version_info`	`version`	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.”