Grafana Cloud

k6 scripted check

k6 scripted checks can execute k6 tests in Synthetic Monitoring. Use k6 scripted checks to monitor transactions and user flows by implementing workflows, custom logic, and validations in JavaScript.

With k6 scripted checks, you can:

  • Define custom user behavior and complex request logic.
  • Leverage the flexibility of a scripting language.
  • Test HTTP/S and WebSocket services.
  • Utilize the k6 API and other JavaScript libraries.
  • Enable OpenTelemetry traces for server-side correlation.
  • Reuse the same k6 script for distinct testing goals.

Synthetic Monitoring - k6 scripted check

How it works

A k6 check runs one iteration of a k6 test at short, frequent intervals to proactively monitor applications and services.

Synthetic Monitoring results are stored as Prometheus metrics and Loki logs, which allow you to set up Grafana alerts for custom notifications and incident management.

The k6 scripts in Synthetic Monitoring are broadly compatible with other k6 products, like the k6 CLI and Grafana Cloud Performance Testing. This allows you to reuse the same k6 script for various use cases, enhancing testing productivity and coverage.

Get started

You can write and execute a k6 script from the code editor in the Synthetics UI.

  1. On the left-side menu, select Testing & synthetics and then Synthetics.
  2. Click Create new check or Add new check.
  3. Choose k6 scripted as your check type.
  4. Set the value for the required options.
  5. Edit or copy your k6 script under Script.
  6. Schedule or run the check.
    1. Click Save to schedule the check.
    2. Click Test to run the k6 script.

For development and debugging, you can write and execute the k6 script from your local machine using the k6 CLI and your IDE. After completing the k6 script, create a new scripted check or update the script of an existing one.

The Synthetics script editor includes a few scripts with basic examples. To get started implementing your first k6 scripts, refer to:

Select a k6 version channel

You can choose which k6 version channel runs the check from the k6 version channel dropdown on the Script step. For details, refer to Manage k6 versions.

Options

The list of common options to all check types:

OptionDescription
EnabledWhether the check is enabled or not.
Job nameRefer to the check name. Check metrics include a job label with the value of this option.
TargetTarget of the check request. Check metrics include an instance label with the value of this option.
Probe locationsThe locations where the check should run from. Check metrics include a probe label with the value of the probe location running the check.
FrequencyThe frequency the check should run in seconds. The value can range from 60 to 3600 seconds. Only the sm_check_info metric includes the frequency label.
TimeoutMaximum execution time for the check. The value can range from 1 to 180 seconds.
Custom labels(Optional) Custom labels applied to check metrics. Refer to Custom labels for querying instructions.

Additionally, k6 scripted checks have the following options:

OptionDescription
ScriptThe k6 script to execute periodically. For further details, refer to k6 compatibility.

Supported k6 Options

k6 options can be used to configure a wide range of features when running the k6 script. In Synthetic Monitoring, k6 options can only be set in the script options object:

JavaScript
export const options = {
  tags: { foo: 'bar' },
  userAgent: 'MyK6UserAgentString/1.0',
};

Several k6 options don’t apply in the context of Synthetic Monitoring. Here is the list of supported options:

k6 OptionDescription
batchMax number of simultaneous connections of a http.batch() call
batch-per-hostMax number of simultaneous connections of a http.batch() call for a host
discardResponseBodiesSpecify whether response bodies should be discarded
httpDebuglog all HTTP requests and responses
insecureSkipTLSVerifyA boolean specifying whether k6 should ignore TLS verifications for connections established from code
maxRedirectsThe maximum number of HTTP redirects that k6 will follow
noConnectionReuseA boolean specifying whether k6 should disable keep-alive connections
setupTimeoutSpecify how long the setup() function is allow to run before it’s terminated
systemTagsSpecify which System Tags will be in the collected metrics
tagsSpecify tags that should be set test-wide across all metrics
teardownTimeoutSpecify how long the teardown() function is allowed to run before it’s terminated
throwA boolean specifying whether to throw errors on failed HTTP requests
tlsAuthA list of TLS client certificate configuration objects
tlsCipherSuitesA list of cipher suites allowed to be used by in SSL/TLS interactions with a server
tlsVersionString or object representing the only SSL/TLS version allowed
userAgentA string specifying the User-Agent header when sending HTTP requests

Metrics

Synthetic checks store their results as Prometheus metrics, including the list of common metrics to all check types:

MetricDescription
probe_all_duration_secondsReturns how long the probe took to complete in seconds (histogram).
probe_duration_secondsReturns how long the probe took to complete in seconds.
probe_all_successDisplays whether or not the probe was a success (summary).
probe_successDisplays whether or not the probe was a success.
sm_check_infoProvides information about a single check configuration.

k6 metrics

Scripted checks also collect the metrics produced by k6 and store them as Prometheus metrics.

k6 has two types of metrics:

  • Built-in metrics: These are metrics collected by every k6 test, such as data received and total number of requests.
  • Custom metrics: These are metrics that you can create in your test script to measure anything that’s specific to your system or business logic. In Prometheus, they’re renamed to probe_K6_METRIC_NAME and mapped to Prometheus gauges.

k6 built-in metrics are transformed in Synthetic Monitoring as follows:

MetricAdditional labelsDescription
probe_check_success_ratecheck, scenarioThe pass/fail rate of assertions (calls to check()). The check label identifies the assertion by name. The value can range between 0 (all failed) and 1 (all passed).
probe_checks_totalcheck, result, scenarioThe number of passing and failing assertions (calls to check()). The check label identifies the assertion by name. The result label can have a value of pass or fail.
probe_data_received_bytesscenarioThe total data received for all requests made while executing the script. It corresponds to the data_received metric.
probe_data_sent_bytesscenarioThe total data sent for all requests made while executing the script. It corresponds to the data_sent metric.
probe_http_all_duration_secondsmethod, name, phase, proto, scenario, status, tls_version, urlHistogram of HTTP request duration by phase.
probe_http_duration_secondsmethod, name, phase, proto, scenario, status, tls_version, urlDuration of HTTP request by phase, in seconds. This is the combined total of the http_req_blocked, http_req_connecting, http_req_receiving, http_req_sending, http_req_tls_handshaking, and http_req_waiting k6 HTTP metrics.
probe_http_error_codemethod, name, proto, scenario, status, tls_version, urlThe k6 error code for the HTTP request.
probe_http_got_expected_responsemethod, name, proto, scenario, status, tls_version, urlThe expected_response tag set on HTTP requests by k6. By default, response statuses between 200 and 399 are true. For more details, refer to k6 HTTP request tags.
probe_http_infomethod, name, proto, scenario, status, tls_version, urlIncludes additional labels associated with an HTTP request, such as HTTP version and TLS version. Always returns 1.
probe_http_requests_failedmethod, name, proto, scenario, status, tls_version, urlIndicates whether the individual HTTP request failed.
probe_http_requests_failed_totalmethod, name, proto, scenario, status, tls_version, urlThe number of failed HTTP requests while executing the script.
probe_http_requests_totalmethod, name, proto, scenario, status, tls_version, urlThe number of HTTP requests initiated while executing the script.
probe_http_sslmethod, name, proto, scenario, status, tls_version, urlIndicates whether TLS was used for the request.
probe_http_status_codemethod, name, proto, scenario, status, tls_version, urlResponse HTTP status code.
probe_http_total_all_duration_secondsmethod, name, proto, scenario, status, tls_version, urlHistogram of total HTTP request duration.
probe_http_total_duration_secondsmethod, name, proto, scenario, status, tls_version, urlTotal duration of the HTTP request in seconds. It corresponds to the http_req_duration metric.
probe_http_versionmethod, name, proto, scenario, status, tls_version, urlReturns the HTTP version of the response.
probe_iteration_all_duration_secondsscenarioHistogram of the k6-reported iteration duration.
probe_iteration_duration_secondsscenarioReturns the k6-reported iteration duration in seconds. It corresponds to the iteration_duration metric.
probe_script_all_duration_secondsNoneHistogram of the k6-reported scripted-check execution time.
probe_script_duration_secondsNoneReturns the k6-reported scripted-check execution time in seconds.

Visualization

You can query all the produced check metrics with Grafana Explore, where you can create custom panels and add them to your dashboards.

Additionally, each check includes a dashboard displaying the results of the most relevant metrics. To learn more about the various visualization options, refer to Analyze results.

k6 scripted check dashboard

Compatibility

Grafana Cloud Synthetic Monitoring has the following limitations for k6 scripts, compared to running them locally or using Grafana Cloud k6:

Workload options

Each k6 check runs only one iteration of the test. The system ignores options such as vus, duration, stages, and iterations.

Timeout

k6 checks have a maximum execution time. Configure this limit with the Timeout option in the UI.

k6 CLI

You can’t use the k6 CLI to run or upload k6 scripts to Grafana Cloud Synthetic Monitoring.

Other k6 APIs

Thresholds aren’t supported.

Labels

Custom labels that you define in the UI aren’t included in k6 metrics. Non-k6 metrics don’t include labels that you define in the k6 tags option.

Load local files

For security reasons, probes can’t load local files. k6 APIs such as open, fs, and grpc.load (non-reflection) aren’t supported.

To import local modules or libraries, use a bundler to build your k6 script with its dependencies locally, then copy the output into the script option.