--- title: "System labels in Synthetic Monitoring | Grafana Cloud documentation" description: "Complete reference of the labels Synthetic Monitoring applies to check metrics and logs, including the reserved label names that can't be used as custom labels." --- > For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/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](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/migrate-labels/). 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](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/analyze-results/check-metrics/), for every check type. Expand table | 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. Expand table | Label | Description | |--------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `check_name` | The check type identifier, for example `http`, `multihttp`, or `scripted`. For all values, refer to [Check type identifiers](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/create-checks/checks/#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 Expand table | 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 Expand table | 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. Expand table | 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. Expand table | 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. Expand table | 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 Expand table | 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](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/analyze-results/system-labels/#common-metric-labels) that appear on check metrics. Check logs carry the following labels. Expand table | 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: Expand table | 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}`](https://synthetic-monitoring-api.grafana.net/api/v1/swagger#/operations/POST_/api/v1/check/labels/:key) endpoint. For more information about managing checks as code, refer to [Provision Synthetic Monitoring resources](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/set-up/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](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/create-checks/checks/k6/) and [k6 browser](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/create-checks/checks/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](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/migrate-labels/), 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.