Browser test metrics
Learn about the metrics captured by browser tests in Splunk Synthetic Monitoring.
Metrics in Splunk Synthetic Monitoring are numeric indicators of site performance that synthetic tests capture in each run of a test.
Browser tests capture 40+ metrics that offer a complete picture of your website performance. You can also configure custom metrics to gather the information you care about most. Browser tests capture metrics in three contexts:
Some metrics like synthetics.duration.time.ms can be both page-level and transaction-level. If you choose not to provide a page_position or transaction_position dimension (as noted below) the metric is aggregated across pages and transactions.
Dimensions
All Splunk Synthetic Monitoring metrics contain the following dimensions:
Dimensions | Description |
|---|---|
|
|
|
|
| The ID of the location for this run. |
| The ID of this test. |
| The test type dimension for browser tests is set to |
| The test property is the human readable name of the |
| The location property is the human readable name of the |
All metrics have a test_id and location_id dimension. The test and location properties are attached to those dimensions respectively whenever possible to make the data more readable.
Test-level metrics
Metric label | Source metric name | Description |
|---|---|---|
Uptime |
| In browser tests, the Uptime represents the percentage of non-failed test runs. Uptime is calculated by taking the average score of all runs in the selected time frame, where a successful run receives a score of 100 and a failure receives a score of 0. |
Downtime |
| The percentage of failed runs within the selected time frame. Downtime is calculated by taking the average score of all runs in the selected time frame, where a failed run receives a score of 100 and a successful run receives a score of 0. |
Run count |
| Total number of runs for the test. This metric contains dimensions such as |
Run-level duration |
| The total duration of the entire run, including all pages and synthetic transactions. |
Page-level metrics
Browser tests in automatically capture a set of 45 default metrics for each page load. These metrics are grouped into several categories. See the tables below for details on all default page-level metrics.
Page-level metrics include an additional page_position dimension that refers to the position of the page within the test. The position of the first page in the test is 0, the second page has position 1, and so on. If you choose a page-level metric in the Performance KPIs chart or in a detector without specifying a page in the page_position dimension, the metric value is aggregated across all pages. If the metric exists as a transaction-level metric, the aggregation is across both pages and transactions.
- Performance timings
Performance timings capture information about how long it takes resources on the page to render.
Tip: Some performance timings require interactive metric collection to be enabled: On the test's edit page, select . If you don't enable this setting, these metrics appear in the UI asnullor0.Metric label
Source metric name
Description
DOM complete time
synthetics.dom_complete.time.msTime until the Document Object Model (DOM) and all of its subresources are ready.
DOM interactive time
synthetics.dom_interactive.time.msTime until the Document Object Model (DOM) is fully loaded and processed.
DOM load time
synthetics.dom_load.time.msTime until the Document Object Model (DOM) has loaded, and the initial markup has been parsed. This metric corresponds to the browser
DOMContentLoadedevent.Time to first byte (TTFB)
synthetics.ttfb.time.msTime from the start of the first request until receiving the first byte of the first non-redirect request.
3xxredirects increase the duration of this time.Duration
synthetics.duration.time.msTotal amount of time spent on this page. This is the time from the start of the first request until either the end of the last request, or the end of the last step executed on this page, whichever is later. Summing all page durations is equivalent to the run duration (
synthetics.run.duration.time.ms).First paint time
synthetics.first_paint.time.msTime until the browser renders anything other than the default background.
First contentful paint time
synthetics.first_contentful_paint.time.msTime until the browser first renders any content.
First meaningful paint time
synthetics.first_meaningful_paint.time.msTime until the biggest above-the-fold layout change has happened and web fonts have loaded.
Start render time
synthetics.start_render.time.msTime until the first pixel of content is drawn.
First CPU idle
synthetics.first_cpu_idle.time.msTime until the page is minimally interactive and will respond to user input in a reasonable amount of time.
Time to interactive
synthetics.tti.time.msTime until the page is first expected to be usable and will respond to user input quickly.
Onload time
synthetics.onload.time.msTime until the page has loaded. This corresponds to the browser load event.
Visually complete time
synthetics.visually_complete.time.msTime until all above-the-fold content has finished rendering.
Speed index
synthetics.speed_index.time.msA calculated metric that represents how quickly the page renders above-the-fold content.
- Web vitals
Web vitals are metrics that represent user experience in terms of loading, interactivity, and visual stability.
Tip: Some web vitals require interactive metric collection to be enabled: On the test's edit page, select . If you don't enable this setting, these metrics appear in the UI asnullor0.Metric label
Source metric name
Description
Largest contentful paint (LCP)
synthetics.webvitals_lcp.time.msMeasures page loading times as perceived by users. The LCP metric reports the render time of the largest content element visible within the viewport.
Total blocking time (TBT)
synthetics.webvitals_tbt.time.msCaptures issues that affect interactivity. TBT is a synthetic alternative for Interaction to Next Paint (INP), which measures page responsiveness to user input. Optimizations that improve TBT in the lab can also help improve INP for your users.
Cumulative layout shift (CLS)
synthetics.webvitals_cls.scoreMeasures page stability. CLS is based on a formula that tallies up how many times the components on the page move or "shift" around while the page is loading. Fewer shifts are better.
To learn more about web vitals, see https://web.dev/vitals/ in the Google developer documentation.
- Connection timings
Connection timings metrics capture information about the latency of your site’s connection to its server.
Metric label
Source metric name
Description
DNS time
synthetics.first_request.dns.time.msTime required to resolve a host name from the DNS server.
TCP connect time
synthetics.first_request.connect.time.msTime it takes to create a TCP connection.
Receive time
synthetics.first_request.receive.time.msTime required to read the entire response from the server.
Send time
synthetics.first_request.send.time.msTime required to send HTTP data to the server.
TLS time
synthetics.first_request.tls.time.msTime required for TLS/SSL negotiation.
Wait time
synthetics.first_request.wait.time.msTime from when a request is finished until the time the first byte of the response is received for the first request in a page.
- Resource and error count metrics
Resource and error count metrics capture information about the number and types of resources on a page.
Metric label
Source metric name
Description
Client error count
synthetics.resource_request.error.countNumber of client responses with a status code between 400 and 499. The error type is indicated in the
http.status_code_typedimension.Connection error count
synthetics.resource_request.error.countNumber of connection responses where the status code is 504 or 0 (a request aborted by the browser). The error type is indicated in the
http.status_code_typedimension.Server error count
synthetics.resource_request.error.countNumber of server responses where the status code is 500 or higher (excluding 504). The error type is indicated in the
http.status_code_typedimension.Error count
synthetics.resource_request.error.countTotal count of responses with status codes greater than or equal to 400. This is a calculated metric, equivalent to the total number of client, connection, and server errors.
HTML count
synthetics.resource_request.countNumber of requests for HTML documents. The content type is indicated in the
content_typedimension.Image count
synthetics.resource_request.countNumber of requests for images. The content type is indicated in the
content_typedimension.JavaScript count
synthetics.resource_request.countNumber of requests for JavaScript files. The content type is indicated in the
content_typedimension.CSS count
synthetics.resource_request.countNumber of requests for CSS files. The content type is indicated in the
content_typedimension.Video count
synthetics.resource_request.countNumber of requests for videos. The content type is indicated in the
content_typedimension.Font count
synthetics.resource_request.countNumber of requests for fonts. The content type is indicated in the
content_typedimension.Other count
synthetics.resource_request.countNumber of requests for all other resources that are not HTML, image, JavaScript, CSS, video, or font requests.
Request count
synthetics.resource_request.countTotal number of requests made. This is a calculated metric, equivalent to the sum of all resource type counts (HTML, image, JavaScript, CSS, video, font and other counts).
- Content size metrics
Content size metrics capture information about the size of resources on a page. Content sizes are calculated using the transfer size (or on-the-wire size) of each request.
Metric label
Source metric name
Description
Total content size
synthetics.resource_request.size.bytesTotal size (in bytes) of all content loaded. This is equivalent to the total sum of all resource type sizes (HTML, image, JavaScript, CSS, video, font and other sizes).
Total HTML size
synthetics.resource_request.size.bytesTotal size (in bytes) of all HTML content loaded. The content type is indicated by the
content_typedimension.Total image size
synthetics.resource_request.size.bytesTotal size (in bytes) of all image content loaded. The content type is indicated by the
content_typedimension.Total JavaScript size
synthetics.resource_request.size.bytesTotal size (in bytes) of all JavaScript content loaded. The content type is indicated by the
content_typedimension.Total CSS size
synthetics.resource_request.size.bytesTotal size (in bytes) of all CSS content loaded. The content type is indicated by the
content_typedimension.Total video size
synthetics.resource_request.size.bytesTotal size (in bytes) of all video content loaded. The content type is indicated by the
content_typedimension.Total font size
synthetics.resource_request.size.bytesTotal size (in bytes) of all font content loaded. The content type is indicated by the
content_typedimension.Total other size
synthetics.resource_request.size.bytesTotal size (in bytes) of all other resources that are not HTML, image, JavaScript, CSS, video, or font requests.
- Score metrics
Splunk Synthetic Monitoring currently offers one calculated score metric to offer a gauge of how your page is performing against an established scale.
Tip: Score metrics require interactive metric collection to be enabled: On the test's edit page, select . If you don't enable this setting, these metrics appear in the UI asnullor0.Metric label
Source metric name
Description
Lighthouse Performance Score
synthetics.lighthouse.scoreA weighted aggregation of several browser test metric values calculated using v10 of the Lighthouse scoring algorithm. See https://web.dev/performance-scoring/ in the Google developer documentation to learn more about Lighthouse scoring.
Transaction-level metrics
Splunk Synthetic Monitoring captures three metrics for each synthetic transaction. Using these metrics, synthetic transactions can act as custom timers on business-critical workflows in your application and receive metrics tailored to the workflows you care about. See Add synthetic transactions to your browser test to learn how to set up Business Transactions.
Transaction-level metrics include two additional dimensions that correspond to each specific transaction within the test: transaction and transaction_position. The transaction dimension contains the name of the corresponding transaction, and the that refers to the position of that transaction within the test. The position of the first transaction in the test is 0, the second transaction has position 1, and so on. If you choose a transaction-level metric in the Performance KPIs chart or in a detector without specifying a transaction in the transaction dimension, the metric value is an aggregate of the metric across all transactions. If the metric exists as a page-level metric, the aggregation is across both pages and transactions.
Metric label | Source metric name | Description |
|---|---|---|
Duration |
| Total duration of the synthetic transaction. |
Requests |
| Total number of requests made during the synthetic transaction. |
Total size |
| Total size (in bytes) of the content loaded during the synthetic transaction. |
See also
To get even more value out of your synthetic metrics, use the Splunk Observability Cloud metrics engine to create custom metrics, charts, and detectors. See the following links for more information:
To build charts and dashboards using your metrics, see Dashboards in Splunk Observability Cloud.
To create static threshold detectors natively in Splunk Synthetic Monitoring, see Detectors and alerts.
To build more advanced detectors using the Splunk Observability Cloud metrics engine, see Introduction to alerts and detectors in Splunk Observability Cloud.
To learn more about metrics in Splunk Observability Cloud, see Metrics, data points, and metric time series in Splunk Observability Cloud.