 |
VOOZH | about |
|
VOOZH | about |
The test details page opens after a Synthetic browser test executes and is organized into four tabs: Activity, Test Runs, Performance, and Properties. Use these tabs to monitor uptime, inspect individual runs, review aggregate performance metrics, and manage test configuration. When a run fails, see Failed results for troubleshooting tools such as AI failure summaries and screenshot comparison.
On the Activity tab, you can see:
On the Test Runs tab, you can see all individual runs of your test. Filter by status (passed or failed), run type, location, or device, and click any row to inspect that run in detail.
Browser test runs include components such as screenshots, page performance data, errors, resources, and backend traces to help troubleshoot your test failure.
To view related sessions and available replays in the RUM Explorer, click View Session in RUM. To access a user session for a particular action or step in Session Replay, click Replay Session. For more information, see Explore RUM & Session Replay in Synthetic Monitoring.
Every executed test step contains a screenshot of the step action, a link to the session in Session Replay, the step description, starting URL for a given step, step ID, step duration, and page performance information.
Click the Errors pill to access the Errors & Warnings tab and examine a list of errors separated by error type (js or network) and status (the network status code).
The Errors & Warnings tab displays a list of errors separated by error type (js or network) and status (the network status code).
The error type is logged when the browser test interacts with the page. It corresponds to the errors collected between the time the page is opened and the time the page can be interacted with. The maximum number of errors that can be displayed is 8, for example: 2 network + 6 js errors.
Click the Resources pill to access the Resources tab and examine the combination of requests and assets, including the total step duration time under Fully Loaded and the CDN provider serving the resources.
You can filter resources by type and search by name in the search bar. The maximum number of resources that can be displayed is 100. Resources are ordered by the time when they start and display the first 100 in Datadog.
For Fetch and XHR resources, click on a resource row to view its request and response headers and body. Payload details are only available when Capture HTTP payloads is enabled in the test’s advanced options.
Click the Traces pill to access the Traces tab and explore APM traces associated with the browser test. While the UI is similar to the Trace View in the Trace Explorer, one browser test step can make multiple requests to different URLs or endpoints. This results in several associated traces, depending on your tracing setup and on the URLs you allowed in for browser tests in the Synthetic Monitoring Settings page.
For more information about cross-product correlation, see the Ease Troubleshooting With Cross-Product Correlation guide.
Step duration represents the time a step takes to be considered fully loaded using the Datadog locator system. For more information, see How Step Duration is Determined in Browser Tests.
If your test reaches the maximum execution time, the timeout message indicates that the total duration includes both test steps and system overhead. As a result, the reported test duration may differ from the sum of individual step durations.
On the Performance tab, you can see aggregate performance metrics across all runs of your test:
Within an individual test run, Largest Contentful Paint and Cumulative Layout Shift are displayed as pills to the right of each step URL. First Input Delay is available as a real metric if you are using Real User Monitoring to collect real user data. For more information, see Monitoring Page Performance.
The Properties tab contains the configuration details, ownership information, and integrations associated with your test. Use the left navigation to switch between sections.
A test result is considered FAILED if it does not satisfy its assertions or if a step failed for another reason. You can troubleshoot failed runs by looking at their screenshots, checking for potential errors at the step level, and looking into resources and backend traces generated by their steps.
When a browser test run fails, Datadog generates an AI failure summary to help you identify the cause and next steps for investigation. Each summary includes:
AI failure summaries appear on the test run details page for any failing browser test run. Treat them as a starting point for investigation, not as authoritative root cause analysis, because LLM-generated content can contain inaccuracies. Use the 👍 and 👎 buttons on the summary to share feedback and help improve future results.
To help during the investigation, click Compare Screenshots to receive side-by-side screenshots of the failed result and the last successful execution. The comparison helps you to spot any differences that could have caused the test to fail.
Note: Comparison is performed between two test runs with the same version, start URL, device, browser, and run type (scheduled, manual trigger, CI/CD). If there is no successful prior run with the same parameters, no comparison is offered.
Element located but it's invisibleCannot locate elementSelect did not have optionForbidden URLGeneral test failureAlerts from your Synthetic test monitors appear on the timeline in the Activity tab, where you can review alert triggers, recoveries, and test modifications alongside the global uptime graph. To search for alerts from Synthetic tests in the Events Explorer, navigate to Events > Explorer and enter @evt.type:synthetics_alert in the search query. For more information, see Using Synthetic Test Monitors.
Additional helpful documentation, links, and articles:
| |
