The Browser Result Details view contains information about Browser check results in a number of charts, graphs and tables. This view is most useful for analyzing browser results for scenarios. The type of information displayed in the view depends on the check type. For a scenario, several aspects of the check are shown in different areas. For example, a Scenario Check could have several areas dealing with different aspects of the scenario:
...
Depending on the type of check, different areas may be available in the view.
Access & Bookmarks
In most cases you can access the Details view by clicking a check wherever it is presented. Depending on the view you are in, the exact method to access the details varies. Whenever you access check Check Details, a bookmark is placed at the top of the window. The results bookmark shows the check url / name:
...
A similar bookmark is created for Result Details. The results bookmark shows the timestamp:
...
This allows you to keep a number of checks in the bookmarks bar and move between them by clicking the respective bookmark.
Clicking a bookmark will take you to the appropriate Check Details or Result Details detail viewUsers can use the Check Result page to view information regarding which domains loaded during the check run, the slowest URLs which loaded, any errors which occurred during the check execution, and more.
...
Result Message
The Result Message of a Browser Check contains useful summarizing information. The following message is an example of a result message:
6 steps, 6 pages, 76 urls, 32902/857026 sent/received bytes
6 steps - Obsolete data point. The number of steps will always equal the number of pages.
6 pages - Of course, pages organize Browser Check URL calls into logical functions (such as navigating to a certain page). The number of pages in the scenario can be altered using the custom command insertPageBreak.
76 urls - the number of URLs which were loaded throughout the entirety of the check.
32902/857026 sent/received bytes - the number of uncompressed bytes sent to and received by the web server throughout the duration of the scenario.
Metrics Section
...
The Metrics Section contains useful information regarding browser metrics.
Total browser render time is the response time from the start of the navigation until the last request is completed.
Total response time is the sum of the response time of all the objects that were loaded during the execution. Total response time is calculated serially.
Total page size is the sum of the response sizes of all loaded objects in bytes.
DOM content loaded is the time it took for the check to reach the DOM content loaded event after navigation started.
DOM complete is the time it took for the check to reach the DOM complete event after navigation started.
DNS lookup is the time the check took to perform DNS lookup for the scenario.
Click on the arrows to the left and right of the metrics to access the previous and next Check Result.
Domains
The Domains section displays a table containing the domains accessed in the check. For each, aggregated information about regarding traffic volumes and percentages percentage is shown.
...
Column | Description |
|---|---|
Domain | URL for the domain |
Size | Absolute traffic size and percentage of the total number of received bytes (as seen in the sent/received portion of the result message and the Metrics section). The percentage metric here refers to a percentage of the “Received Size” of the check - in the above screenshot, 824 KB is 98.4% of the “Received Size” of the check |
Time | Absolute traffic time and percentage of the time it took all pages to load. Note that this is different from the scenario runtime - in the above screenshot, 4 857 ms is 99.2% of 4895 ms, the total time it took all the scenarios to load |
Count | Number of urls and percentage |
Timeline | Graphical representation of the transactions. |
Timeline
In order to view the legend for the timeline, point the cursor at the domain url in the table.
A tooltip with the legend is displayed.
Domains Legend
...
Colored bars correspond to the timings indicated in the Legend |
10 Slowest URLs
The Slowest URLs table shows a list containing the urls with the slowest response times in the check:
...
Column | Description |
|---|---|
# | Order of access / order in scenario |
Time | Response time of the URL |
In this unnamed column, you will see an icon. Hover over the icon to see the type of the URL in question. Example types include | |
Url | Accessed URL and the HTTP method used to request the URL |
Timeline | Graphical representation of the transactions. Colored bars correspond to the timings indicated in the Legend |
Slowest URL Legend
The Slowest URL Legend window is displayed when you point at a domain url in the table. It shows explanations for explains the colors used in the diagram. It also shows the actual time for each of the categories.
...
Item
...
Description
...
DNS Lookup
...
Time for DNS query and receive the response.
...
Connecting
...
Time to establish a connection.
...
Sending Request
...
Outgoing request message processing.
...
Waiting for Response
...
Time it took for the target system to return the first response which is the Response Headers.
...
Receiving Data
...
Time to complete response from the URL/method.
Elapsed Time
The Elapsed Time Per Page section shows the distribution of response times for the pages in a scenario .
View
...
Column
...
Description
...
Step
...
Name of scenario step.
...
Avg. Time
...
Average response time in the step.
...
Percentage
...
, reveals information about the URL timing, and displays the Server IP address for the domain which is accessed:
...
This information can be very valuable when diagnosing timing issues with individual URLs within a scenario. See the Legend for more information on DNS Lookup, Connection, SSL Handshake, etc.
Errors
The Errors section displays errors encountered during the scenario run for the check, if any exist. For each page that has errors, a table is shown which contains reveals pertinent information about the errors.
...
each error:
...
Column | Description | Comment |
|---|---|---|
# | ID number for accessed page |
The Jump To URL link lets you navigate to the URL in the waterfall where the error occurred |
HTTP Code | Returned HTTP Status |
Code |
|
Error | Error message from the application |
, if any |
|
Time | Elapsed time for the step where the error occurred |
| |
Url | Access HTTP Methods and URL where the error occurred |
When you click a particular URL in the table, detailed information |
regarding the response is shown |
Request | Outgoing request message |
The Open link in the Request column allows you to try to send the request manually |
Response | Incoming response for the request |
In the above screenshot, no responses were returned and all columns contain the response “N/A”. That will not always be the case | |
MIME | MIME Type for the response |
| |
Error log | Log messages for the error |
Jump To URL
In the above screenshot, no errors were logged; all columns contain the response “N/A”. That will not always be the case |
The Jump To URL link lets you navigate to the URL in the Waterfall where the error occurred.:
...
...
The Open link in the Request column allows you to try to send the request manually.:
...
If the request can be sent, you will see data in the “Headers” section.
When you click a particular URL in the table, detailed information about the response is shown.:
...
Error Types
There are a number of error types that can be reported for a step.
Job Timeout
A job timeout error means that the scenario step running time has exceeded the allowed time.
Causes
The job timeout error can mean that a single scenario step runs for too long, due to a coding problem, or some other reason.
There can also be connection issues or very slow - or none at all - responses from the target server.
The default job timeout is 180 seconds.
Redirect Loop
The Redirect Loop error typically indicates that the there isa circular redirection happening with the request.
Causes
The typical cause of this error is a page that redirects to another page which in turn (possibly via multiple other pages) redirects back to the original page.
Redirect loop errors can also occur when the page redirects to itself, possibly due to a programming error or misconfiguration of an
htaccessfile or the web server.Additionally, and more rarely, the error can be trigged if there is no actual loop, but there are too many HTTP redirects before a page is reached that does not also issue a redirect.
Page Timeout
A Page Timeout error happens when the total load time for a single page exceeds the threshold value.
Causes
The page timeout happens after a page has started loading, but no new events are received, and no other page has started loading.
The timeout occurs if a DOM has not been received (
page timeout while waiting for DOM Complete event).It can also occur if there is at least one response missing for one of the sent HTTP requests (
page timeout while waiting for resources).This means that the page is reachable, but for some reason takes a very long time to load, and there is no transfer to a different page.
The default threshold value is 80 seconds.
Changing the value
The Page Timeout value can be changed from the check configuration. Changing the URL Timeout will affect the Page Timeout value. The URL Timeout value is added to 40 to generate a new Page Timeout value.
URL Timeout
The URL Timeout error is triggered whenever the response time for a single URL request exceeds the threshold value.
Causes
Url timeout is setup separately for every URL to track debugger notifications it receives. If no events are received for a URL in urlTimeout seconds then it will be reported as timed out.
Setting
The default threshold value is 40 seconds. This can be configured in the advanced section of the check configuration.
Changing the value
Changing the URL Timeout (Error Types) will affect the Errors Types Page Timeout value. The URL Timeout value is added to 40 to generate a new Page Timeout value.
History Information
The History Information table shows information about the check run.
This information is available if the full browser result information is not relevant for the check type or has been purged.
...
Item
...
Description
...
Severity
...
Check status Severity.
...
Time
...
The timestamp for the check run.
...
Elapsed (ms)
...
Duration of the test.
...
Attempts
...
The number of connection attempts.
...
Result Code
...
...
Message
...
Test Result Message.
Legend
The Legend section shows explanations for the colors used in a diagram. The legend varies slightly depending on which graph or table it relates to. For example, the legend for page information:
...
Domains Legend
The Domains Legend window is displayed when you point at a domain url.
It shows explanations for the colors used in the diagram. It also shows the actual time for each of the categories.
...
Item
...
Description
...
DNS Lookup
...
Time for DNS query and receive the response.
...
Connecting
...
Time to establish a connection.
...
Sending Request
...
Outgoing request message processing.
...
Waiting for Response
...
A Note on Request Timeout
If a URL in your scenario does not return a response within X seconds after the DOM complete is sent, you will see an error informing you that the URL timed out:
...
The number of seconds which the check will wait for request resolutions after DOM complete can be configured in the Edit Check settings:
...
Altering the request activity timeout can help in situations where a certain URL is simply taking a long time to return a response. However, if the URL is not returning a response at all, the URL will fail regardless of the value you enter in the Request Activity Timeout input above.
Screenshots
The Screenshots section displays any screenshots that were taken for the browser run if the check is configured to take screenshots.
...
The screenshots are shown as a timeline with an indicator displaying when the image was taken. Click on an individual screenshot to see a full-screen version of the screenshot. Screenshots are taken at the resolution defined in the Edit Check settings.
| Info |
|---|
Screenshots are inserted into a check at the following times: -when a new page is loaded using the “open” command, “...andWait” commands (such as clickAndWait), and any other command which triggers a new page load within the scenario |
| Note |
|---|
Screenshots are NOT automatically taken when an “InsertPageBreak” command is utilized. |
The URL Waterfall Section
The following diagram explains the different metrics which are displayed in the waterfall for a Browser Check result. These metrics are pulled from the ASM API. If you hover over a URL in the waterfall, detailed information about the URL is shown:
...
Clicking on the dropdown caret to the right of the URL will reveal information about the size and load time of past URL runs, as well as Request and Response header information if “store Request/Response Headers” is enabled in the Edit Check settings:
...
Page Breaks in a Browser Check Result
Page breaks fulfill the need to separate different pages, typically consisting of multiple URL calls, from each other. They are used to organize the set of HTML pages into a single group before the next logical page navigation.
Page breaks are inserted into a browser check result whenever a new page load is triggered during a user journey. Specifically, a new page load is triggered when the “Open” command, the “insertPageBreak” command, and any of the “…andWait” commands (e.g. clickAndWait) are used.
Page breaks are automatically generated and inserted by default. However, there is an option to disable automatic page breaks in the Edit Check section. Page breaks can also be entered manually into scripts via use of the insertPageBreak scenario command
Waterfall Metrics
...
Number on Diagram | Metric Name | Description |
|---|---|---|
1 | Step Nr | The Step (sometimes Page) number |
2 | URL number | The identifier of a URL inside of a Step. This is a counter that is unique per Step and corresponds to a URL inside of the Step |
3 | URL | The complete URL including protocol, hostname, path and query parameters |
4 | HTTP method | The HTTP method used (e.g. GET, POST, PUT) |
5 | HTTP status code | The returned status code from the server (200, 302, 500, etc.) |
6 | URL Offset ms | The time offset in milliseconds from when the URL was initiated by the browser relative to the first URL on the Step |
7 | Blocked duration ms | The time the URL is blocked (aka Queued By Browser) inside of the browser before it is executed |
8 | DNS lookup duration ms | The time it took to perform a DNS lookup/query and receive the result back |
9 | Connect duration ms | The time it took to establish a connection to the target system |
10 | Send duration ms | The time it took to send the request from the browser |
11 | Wait duration ms | The time it took for the target system to return the first response |
(that is, the Response Headers |
Receiving Data
Time to complete response from the URL/method.
Slowest URL Legend
The Slowest URL Legend window is displayed when you point at a url in the table.
Shows explanations for the colors used in the diagram. It also shows the actual time for each of the categories.
...
Item
...
Description
...
Offset
...
Time until start of processing.
...
DNS Lookup
...
Time for DNS query and receive the response.
...
Connecting
...
Time to establish a connection.
...
Sending Request
...
Outgoing request message processing.
...
Waiting for Response
...
Time it took for the target system to return the first response which is the Response Headers.
...
Receiving Data
...
Time to complete response from the URL/method.
Waterfall Legend
The Waterfall Legend section shows explanations for the colors used in the waterfall diagram.
View
...
) | ||
12 | Receive duration ms | The time it took for the complete response to be returned from the target system, including headers and content |
13 | Response time ms | The total network response time for this URL ( |
14 | Received bytes | The number of uncompressed bytes received from the server |
15 | Content mime type | MIME type of the response content |
16 | Blocked url offset ms | A timestamp indicating the offset of the Blocked timing relative from when the URL was started |
17 | DNS lookup URL offset ms | A timestamp indicating the offset of the DNS Lookup timing relative from when the URL was started |
18 | Connect URL offset ms | A timestamp indicating the offset of the Connect timing relative from when the URL was started |
19 | Send URL offset ms | A timestamp indicating the offset of the Send timing relative from when the URL was started |
20 | Wait offset ms | A timestamp indicating the offset of the Wait timing relative from when the URL was started |
21 | Receive URL offset ms | A timestamp indicating the offset of the Receive timing relative from when the URL was started |
22 | Step duration ms | The total amount of time it took all URLs on the page to finish loading. In the following example, the “Step duration” of the page is 6,030ms:  As you can see here, the final URL in the waterfall for this page finished loading between 6 and 7 seconds, roughly matching the 6,030ms reported as the “Step duration”:  For further confirmation, if you hover over the final URL and add the metrics together, you will find the sum of the metrics equals the Step duration: 
|
| Info |
|---|
When the check records Websockets, you can get a detailed view of the recorded data by expanding the relevant result Waterfall row. |
Legend
The Legend section at the bottom of a Browser Check Result page displays the color coding which is used to identify different URL operations for each URL in the result. Hover over the “question mark” icons to learn more about how ASM defines DOM Interactive, DOM Content Loaded, and DOM Complete:
...
Item | Description |
|---|---|
Queued by Browser | Time spent in the browser before executing DNS Lookup or |
Connect. | |
DNS Lookup | Time for DNS query and receive the response. |
Connecting | Time to establish a connection. |
Sending Request | Outgoing request message processing. |
Waiting for Response |
The time it took for the target system to return the first response which is the Response Headers. | |
Receiving Data | Time to complete the response from the URL/method. |
DOM Content Loaded | DOM Content Loaded point. |
Dom Complete
DOM Complete point.
DOM Content Loaded
The |
...
render tree can be constructed: the DOM is ready and there are no stylesheets blocking JavaScript execution. |
...
This measure calculates duration between |
...
the |
...
and |
...
timestamps, to allow for JavaScript frameworks waiting DOM Content Loaded before starting execution. | |
DOM Complete | DOM Complete point. The DOM Complete point is when the resource loading and processing is complete. |
...
History Information
The Scenario Details section History Information table shows information about the scenario used in the check .
...
Column
...
Description
...
Order of access / order in scenario.
...
Time
...
Response time.
...
Type
...
Method of access.
...
Url
...
Accessed URL.
...
Timeline
...
Graphical representation of the transactions.
Masking Values
When command values contain sensitive information, they can be masked. This will prevent the value from being displayed in results.
Example
Let’s assume you use a scenario with the following commands:
...
Command
...
Target
...
Value
...
open
...
/
...
selectWindow
...
null
...
type
...
id=username
...
user1
...
type
...
id=password
| Code Block |
|---|
\{\{${maskapicaPassword}\}\} |
...
clickAndWait
...
_inputunnamed link
If you want to mask the value secretPa$$word in the Check Result page the following steps are required:
Add the command
Storeto store the password as a variable with the prefixmaskapica
Use this variable with the actual command which uses the password.
Your commands should now look like this:
...
Command
...
Target
...
Value
...
store
...
secretPa$$word
...
maskapicaPassword
...
open
...
/
...
selectWindow
...
null
...
type
...
id=username
...
user1
...
type
...
id=password
| Code Block |
|---|
\{\{${maskapicaPassword}\}\} |
...
clickAndWait
...
_inputunnamed link
When Synthetic Monitoring runs a check using this scenario the result will be saved with the executed scenario commands list as the example above. When Synthetic Monitoring shows the check result on the check results page Synthetic Monitoring will recognize that there is a command value which starts with maskapica.
The command’s target will be masked on the the check results page:
...
Command
...
Target
...
Value
...
store
...
*******
...
maskapicaPassword
...
open
...
/
...
selectWindow
...
null
...
type
...
id=username
...
user1
...
type
...
id=password
| Code Block |
|---|
\{\{${maskapicaPassword}\}\} |
...
clickAndWait
...
run. If the check has been purged, only the most basic information regarding the check run will be available:
...
Item | Description |
|---|---|
Severity | Check status Severity |
Time | The timestamp for the check run |
Elapsed (ms) | Duration of the test |
Attempts | The number of connection attempts |
Result Code | Returned HTTP Status Code |
Message | If a result message is available (for example, a failure message), it will be displayed here |