Grafana Cloud
Last reviewed: October 19, 2026

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

Common metric labels

These labels appear on every check metric, for every check type.

LabelDescription
config_versionThe version of the check configuration that produced the result.
instanceThe target of the check.
jobThe job name of the check.
probeThe name of the probe that ran the check.

Together, job, instance, probe, and config_version uniquely identify a check result.

The sm_check_info metric

The labels of the sm_check_info metric provide additional information about the check. Query sm_check_info with other check metrics by joining on the common metric labels.

LabelDescription
check_nameThe check type identifier, for example http, multihttp, or scripted. For all values, refer to Check type identifiers.
frequencyThe check frequency, in milliseconds.
geohashThe geographic coordinates of the probe location, encoded as a geohash.
sm_regionThe region of the probe that ran the check. Renamed from region to free that name for your use.

Histogram metrics

LabelDescription
leThe upper bound of a histogram bucket. Prometheus adds it to histogram bucket series.

Duration metrics for DNS, HTTP, k6 scripted, MultiHTTP, and ping checks

LabelDescription
phaseThe phase of the request, for example resolve, connect, or tls.

TLS metrics

TLS metrics are generated by check types that inspect TLS connections and certificates, such as HTTP and TCP checks.

LabelDescription
cipherThe cipher suite negotiated for the TLS connection.
fingerprint_sha256The SHA-256 fingerprint of the TLS certificate.
issuerThe issuer of the TLS certificate.
serialnumberThe serial number of the TLS certificate.
subjectThe subject of the TLS certificate.
subjectalternativeThe subject alternative names of the TLS certificate.
versionThe TLS version of the connection, for example on the probe_tls_version_info metric.

k6-based check metrics

These labels appear on metrics from k6 scripted, MultiHTTP, and k6 browser checks.

LabelDescription
checkThe name of a k6 check (assertion), for example Status is 200.
nameThe name of the request or measurement target, typically a URL.
resultThe result of the request.
scenarioThe name of the k6 scenario.

HTTP request metrics

These labels appear on HTTP request metrics from k6-based checks.

LabelDescription
methodThe HTTP method of the request, for example GET.
protoThe network protocol of the request, for example HTTP/1.1.
statusThe HTTP status code of the response.
tls_versionThe TLS version negotiated for the connection.
urlThe URL of the request.

k6 browser-based check metrics

LabelDescription
ratingThe web vital rating of a measurement, for example good.

Check logs

The instance, job, and probe labels are the same common labels that appear on check metrics. Check logs carry the following labels.

LabelDescription
instanceThe target of the check.
jobThe job name of the check.
probeThe name of the probe that ran the check.
check_nameThe check type identifier, for example http, multihttp, or scripted.
execution_idA unique identifier for a single check execution. Attached as structured metadata, not as an indexed label.
probe_successWhether the check execution succeeded. Use it to filter logs from failing check runs.
sm_regionThe region of the probe that ran the check.
sourceIdentifies log lines generated by Synthetic Monitoring. The value is always synthetic-monitoring-agent.

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.

When a k6 tag uses a reserved label

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.

When an existing label 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.