--- 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 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](/docs/grafana-cloud/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: Expand table | Label | Where it appears | Description | |----------------------|------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------| | `check` | k6-based check metrics | The name of a k6 check (assertion), for example `Status is 200`. | | `check_name` | `sm_check_info` and check logs | The type of the check, for example `http` or `dns`. | | `cipher` | TLS metrics | The cipher suite negotiated for the TLS connection. | | `config_version` | All check metrics | The version of the check configuration that produced the result. | | `execution_id` | Check logs, as structured metadata | A unique identifier for a single check execution. Attached as structured metadata, not as an indexed label. | | `fingerprint_sha256` | TLS metrics | The SHA-256 fingerprint of the TLS certificate. | | `frequency` | `sm_check_info` | The check frequency, in milliseconds. | | `geohash` | `sm_check_info` | The geographic coordinates of the probe location, encoded as a `geohash`. | | `instance` | All check metrics and logs | The target of the check. | | `issuer` | TLS metrics | The issuer of the TLS certificate. | | `job` | All check metrics and logs | The job name of the check. | | `le` | Histogram metrics | Histogram bucket boundaries. Reserved by Prometheus conventions. | | `method` | HTTP request metrics from k6-based checks | The HTTP method of the request, for example `GET`. | | `name` | k6-based check metrics | The name of the request or measurement target, typically a URL. | | `phase` | Duration metrics for DNS, HTTP, MultiHTTP, and ping checks | The phase of the request, for example `resolve`, `connect`, or `tls`. | | `probe` | All check metrics and logs | The name of the probe that ran the check. | | `probe_success` | Check logs | Whether the check execution succeeded. Use it to filter logs from failing check runs. | | `proto` | HTTP request metrics from k6-based checks | The network protocol of the request, for example `HTTP/1.1`. | | `rating` | Browser check metrics | The web vital rating of a measurement, for example `good`. | | `result` | k6-based check metrics | The result of the request. | | `scenario` | k6-based check metrics | The name of the k6 scenario. | | `serialnumber` | TLS metrics | The serial number of the TLS certificate. | | `sm_region` | `sm_check_info` and check logs | The region of the probe that ran the check. Renamed from `region` to free that name for your use. | | `source` | Check logs | Identifies log lines generated by Synthetic Monitoring. The value is always `synthetic-monitoring-agent`. | | `status` | HTTP request metrics from k6-based checks | The HTTP status code of the response. | | `subject` | TLS metrics | The subject of the TLS certificate. | | `subjectalternative` | TLS metrics | The subject alternative names of the TLS certificate. | | `tls_version` | HTTP request metrics from k6-based checks | The TLS version negotiated for the connection. | | `url` | HTTP request metrics from k6-based checks | The URL of the request. | | `version` | TLS metrics | The 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](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/). ## 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](/docs/grafana-cloud/testing/synthetic-monitoring/set-up/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](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/k6/) and [k6 browser](/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/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](/docs/grafana-cloud/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. ## Next steps - To learn how custom labels work on your check metrics and logs, refer to [Custom labels](/docs/grafana-cloud/testing/synthetic-monitoring/analyze-results/custom-labels/). - To remove the `label_` prefix from your custom labels, refer to [Migrate to un-prefixed labels](/docs/grafana-cloud/testing/synthetic-monitoring/migrate-labels/).