Documentation for automated readers
A curated documentation index is available at: https://grafana.com/llms.txt
A complete documentation index is available at: https://grafana.com/llms-full.txt
These indexes can help with page discovery before fetching individual documents.
This page is also available in Markdown, which may be easier for automated readers and AI tools to parse than HTML. The Markdown version is available at https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/analyze-results/system-labels.md, or by sending Accept: text/markdown to https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/analyze-results/system-labels/. For broader documentation discovery, the curated index is available at https://grafana.com/llms.txt and the complete index is available at https://grafana.com/llms-full.txt.
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.
| Label | Description |
|---|---|
config_version | The version of the check configuration that produced the result. |
instance | The target of the check. |
job | The job name of the check. |
probe | The 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.
| Label | Description |
|---|---|
check_name | The check type identifier, for example http, multihttp, or scripted. For all values, refer to Check type identifiers. |
frequency | The check frequency, in milliseconds. |
geohash | The geographic coordinates of the probe location, encoded as a geohash. |
sm_region | The region of the probe that ran the check. Renamed from region to free that name for your use. |
Histogram metrics
| Label | Description |
|---|---|
le | The upper bound of a histogram bucket. Prometheus adds it to histogram bucket series. |
Duration metrics for DNS, HTTP, k6 scripted, MultiHTTP, and ping checks
| Label | Description |
|---|---|
phase | The 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.
| Label | Description |
|---|---|
cipher | The cipher suite negotiated for the TLS connection. |
fingerprint_sha256 | The SHA-256 fingerprint of the TLS certificate. |
issuer | The issuer of the TLS certificate. |
serialnumber | The serial number of the TLS certificate. |
subject | The subject of the TLS certificate. |
subjectalternative | The subject alternative names of the TLS certificate. |
version | The 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.
| Label | Description |
|---|---|
check | The name of a k6 check (assertion), for example Status is 200. |
name | The name of the request or measurement target, typically a URL. |
result | The result of the request. |
scenario | The name of the k6 scenario. |
HTTP request metrics
These labels appear on HTTP request metrics from k6-based checks.
| Label | Description |
|---|---|
method | The HTTP method of the request, for example GET. |
proto | The network protocol of the request, for example HTTP/1.1. |
status | The HTTP status code of the response. |
tls_version | The TLS version negotiated for the connection. |
url | The URL of the request. |
k6 browser-based check metrics
| Label | Description |
|---|---|
rating | The 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.
| Label | Description |
|---|---|
instance | The target of the check. |
job | The job name of the check. |
probe | The name of the probe that ran the check. |
check_name | The check type identifier, for example http, multihttp, or scripted. |
execution_id | A unique identifier for a single check execution. Attached as structured metadata, not as an indexed label. |
probe_success | Whether the check execution succeeded. Use it to filter logs from failing check runs. |
sm_region | The region of the probe that ran the check. |
source | Identifies 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:
| Operation | Enforcement applies |
|---|---|
| Create a check or probe | Yes, reserved label names are rejected |
| Update an enabled check | Yes |
| Re-enable a disabled check | Yes |
| Disable a check | No, always allowed |
| Delete a check | No |
| List or get checks | No |
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.
Was this page helpful?
Related resources from Grafana Labs


