Documentationbreadcrumb arrow Grafana Cloudbreadcrumb arrow Observe and actbreadcrumb arrow Test and validatebreadcrumb arrow Synthetic Monitoringbreadcrumb arrow System labels
Grafana Cloud

System labels in Synthetic Monitoring

Synthetic Monitoring applies a set of labels to the metrics and logs that your checks generate. These system labels identify the check, the probe, and details of each result, and Synthetic Monitoring depends on them to join metrics, evaluate per-check alerts, and power features in the Synthetic Monitoring app.

This page is a complete reference of the labels Synthetic Monitoring generates. All of these labels are reserved: you can’t use their names as custom labels on your checks or private probes. This prevents your labels from colliding with the labels that Synthetic Monitoring writes to the same metrics and logs.

Note

Reserved label enforcement applies to tenants that have started or completed the label migration. If your custom labels still carry the label_ prefix, you can use any label name, because the prefix already prevents collisions.

Reserved system labels

The following label names are reserved for system use:

LabelWhere it appearsDescription
checkk6-based check metricsThe name of a k6 check (assertion), for example Status is 200.
check_namesm_check_info and check logsThe type of the check, for example http or dns.
cipherTLS metricsThe cipher suite negotiated for the TLS connection.
config_versionAll check metricsThe version of the check configuration that produced the result.
execution_idCheck logs, as structured metadataA unique identifier for a single check execution. Attached as structured metadata, not as an indexed label.
fingerprint_sha256TLS metricsThe SHA-256 fingerprint of the TLS certificate.
frequencysm_check_infoThe check frequency, in milliseconds.
geohashsm_check_infoThe geographic coordinates of the probe location, encoded as a geohash.
instanceAll check metrics and logsThe target of the check.
issuerTLS metricsThe issuer of the TLS certificate.
jobAll check metrics and logsThe job name of the check.
leHistogram metricsHistogram bucket boundaries. Reserved by Prometheus conventions.
methodHTTP request metrics from k6-based checksThe HTTP method of the request, for example GET.
namek6-based check metricsThe name of the request or measurement target, typically a URL.
phaseDuration metrics for DNS, HTTP, MultiHTTP, and ping checksThe phase of the request, for example resolve, connect, or tls.
probeAll check metrics and logsThe name of the probe that ran the check.
probe_successCheck logsWhether the check execution succeeded. Use it to filter logs from failing check runs.
protoHTTP request metrics from k6-based checksThe network protocol of the request, for example HTTP/1.1.
ratingBrowser check metricsThe web vital rating of a measurement, for example good.
resultk6-based check metricsThe result of the request.
scenariok6-based check metricsThe name of the k6 scenario.
serialnumberTLS metricsThe serial number of the TLS certificate.
sm_regionsm_check_info and check logsThe region of the probe that ran the check. Renamed from region to free that name for your use.
sourceCheck logsIdentifies log lines generated by Synthetic Monitoring. The value is always synthetic-monitoring-agent.
statusHTTP request metrics from k6-based checksThe HTTP status code of the response.
subjectTLS metricsThe subject of the TLS certificate.
subjectalternativeTLS metricsThe subject alternative names of the TLS certificate.
tls_versionHTTP request metrics from k6-based checksThe TLS version negotiated for the connection.
urlHTTP request metrics from k6-based checksThe URL of the request.
versionTLS metricsThe TLS version of the connection, for example on the probe_tls_version_info metric.

In this table:

  • All check metrics means every metric a check generates, for every check type. Together, the job, instance, probe, and config_version labels uniquely identify a check result. Synthetic Monitoring uses them to join check metrics with the sm_check_info metric and to evaluate per-check alerts.
  • TLS metrics are generated by check types that inspect TLS connections and certificates, such as HTTP and TCP checks.
  • k6-based checks are the scripted, MultiHTTP, and browser check types.

For the metrics each check type generates and the labels on each metric, refer to the metrics section of each check type.

What happens if you use a reserved label

The Synthetic Monitoring API enforces the reserved label names when you create or change checks and private probes:

OperationEnforcement applies
Create a check or probeYes, reserved label names are rejected
Update an enabled checkYes
Re-enable a disabled checkYes
Disable a checkNo, always allowed
Delete a checkNo
List or get checksNo

If a check or probe uses a reserved label name, the API rejects the request with an error that identifies the conflicting label. Rename the label to save your changes. You can always disable or delete a check, even if it uses a reserved label name.

If you manage checks with Terraform or the API, rename reserved labels in your check definitions. To rename a label key across every check in your tenant in a single request, use the Synthetic Monitoring API POST /api/v1/check/labels/{key} endpoint. For more information about managing checks as code, refer to Provision Synthetic Monitoring resources.

Tags in k6 scripts

Tags that you define in a k6 script aren’t validated against the reserved label names, because Synthetic Monitoring doesn’t inspect the contents of your script. If a k6 tag name collides with a reserved system label name, Synthetic Monitoring overwrites your tag value with its own value on metrics. Check logs are unaffected, because k6 tags aren’t indexed as labels.

For more information about how k6 tags appear on your data, refer to the k6 compatibility section of the k6 scripted and k6 browser check documentation.

If a label you use becomes reserved

Synthetic Monitoring occasionally reserves new label names after your tenant has migrated, for example when a new check type introduces new metrics. This is different from the initial label migration, which requires you to rename any labels that collide with existing reserved names before you can proceed.

If a label you already use becomes reserved later:

  • Your label keeps working. Your checks continue to run and emit your value for that label. Synthetic Monitoring doesn’t overwrite or drop your data.
  • System features tied to the new label don’t apply to affected checks. Any new functionality that depends on the reserved label is unavailable for checks that carry your conflicting label, until you rename it.
  • The API blocks edits to affected checks. Updates to a check that carries the conflicting label are rejected until you rename the label. The check continues to run in the meantime, and you can still disable or delete it.
  • In-app warnings identify affected checks. The Synthetic Monitoring app flags checks with label conflicts so you can find and fix them.

Next steps