The following sections only pertain to Browser Checks - you will not be able to specify Returned Value for ZebraTester checks, for example. For components which are editable for every check type, see Editing Checks | Edit Check Components Common to All Check Types.

Check Information

Open

Tags

See Editing Checks | Tags.

Enabled

See Editing Checks | Enabling and Disabling Checks .

Returned Value

Open

In the above image, (ms) denotes “milliseconds” and (b) denotes “bytes”.

• Total Browser Render Time is the response time from the start of the navigation till the last request is completed.

• Total Response Time is the sum of the response time of all objects which were loaded during the execution. “Total response time” measures serial execution!

• Total Page Size is the sum of the response size of all loaded objects in bytes.

• DOM Content Loaded is the time from the start of the navigation until the “DOM Content Loaded” event.

• DOM Complete is the time from the start of the navigation until the “DOM Complete” event.

• DOM Interactive is the time from the start of the navigation until the “DOM Interactive” event.

• DNS Lookup is the DNS lookup time.

Web Browser

It is possible to change the browser name and version from within the Edit Check settings.

To add a scenario, click on the green “plus sign” icon to bring up the “Add Scenario” box:

Specify the desired name of the scenario and upload an .html or .side file and click “Save”:

To edit a scenario, click on the “pad and paper” icon to show the “Edit Scenario” dialog:

Individual files can be deleted from the scenario with the “delete file” button. The scenario can be replaced by a different scenario, or a newer version of the same scenario by uploading a locally stored scenario file. Refer to the article Understanding the Edit Scenario Page for information on the Debug Scenarios functionality.

Browser Behavior

Custom Headers

You can add custom Headers and Header Values in the “Custom Headers” field. For example, if you would like to add a custom User-Agent to the check, type “User-Agent” in the Header field and type a value of your choice in the Header Value field. Make sure to click the green “Plus” sign to apply the custom header!

A common use case for Custom Headers involves utilizing a specific custom header (for example, “User-Agent: Apica”) in order to bypass bot protection for a specific website.

Custom Header Placeholders

It is possible to use the following placeholders within Custom Headers in order to pass dynamic information regarding the check to the application the check is accessing. This can be helpful when a URL call needs to pass unique URL-specific information along to the application. Currently, the following placeholders are available:

Block

Block rules are often an important part of a check configuration, especially for checks which load many URLs. Block rules utilize the wildcard syntax; generally, you should include a wildcard before and after any string pattern you wish to block. For example, if you wish to block all URLs coming from http://example.com , use the block pattern *http://example.com *. If you wish to block only a certain URL or URLs on a certain subdomain, use the block pattern *example.com/firstSubdomain/secondSubdomain* (of course, firstDomain and secondDomain are arbitrary values and should be replaced with the path of the URL(s) you want to block). If you wish to block a certain URL with a certain subtype, use the block pattern *example.com/firstSubdomain/*.woff*. Again, these are arbitrary values; the importance lies in the placement of the wildcard character which will block any value before and after it until it reaches another defined character, per the definition of a wildcard.

Disable Automatic Page Breaks

Disables the insertion of automatic page breaks which are generally inserted when the ASM scenario runs the “open” and any of the “…andWait” commands (e.g. clickAndWait). If automatic insertion of page breaks is disabled in the Browser Behavior section, page breaks can still be entered via the ASM scenario using the insertPageBreak command.

Enable VDMS Debug Headers

When the VDMS option is enabled, Edgecast X-EC-Debug headers are included, containing debugging information.

Enable Akamai Pragma Headers

Enabling the Akamai Pragma Headers options adds a header to the request.

Enable DynaTrace PurePath

When the DynaTrace PurePath option is enabled, a request header is added (overriding any existing header).

AppDynamics SnapShots

When the AppDynamics Snapshots option is enabled, transaction snapshots provided by AppDynamics are included in check results. This option will only be available if you have installed AppDynamics. If you have not enabled AppDynamics for your account, you will see the message “You haven’t installed AppDynamics” instead, with a link to the AppDynamics configuration page in ASM:

Screen Resolution

The browser screen resolution to use when accessing the URL. Default resolution is 1280 x 1024. Any screenshots displayed in the check Results will be taken using this screen resolution.

Browser Data

The check can be configured to store request and response headers in the Browser Data section:

When Request and Response headers are stored, every URL in the URL Waterfall section of a check result will contain additional request and response header information:

Screenshots & Filmstrips

Screenshots

You can instruct the check to take a screenshot during different intervals. If you want to save screenshots for your check, you can either elect to save screenshots for the check run when the check changes status (for example, from Informational to Fatal) or when the check fails.

The following screenshot shows the default options for screenshots:

Filmstrips

Filmstrips are a deprecated feature of ASM. They are available for Firefox checks and Chrome v23 and v55 checks. Filmstrips take screenshots at certain time-based frequencies during the check run, providing a very visual representation of the user journey.

Blurring Mode

It is possible to set a “Blurring Mode” for screenshots which will hide sensitive data from being seen on the Check Results page. There are 4 different blurring modes - use the mode which will effectively hide the information you do not wish to show to an end user who can view Check Results but does not have access to the Edit Check page.

Severity Handling

The Severity Handling section allows users to configure rules which will affect the returned Severity of the check (Informational, Warning, Error, or Fatal).

Severity Mapping

Severity Mapping allows a user to manually change the default severity that would be assigned to a certain URL or set of URLs when a certain HTTP status code is returned. Severity Mapping is generally used when a user wishes to “ignore” a URL failure or to map it to a lesser severity. For example, a user who receives 404 status codes for a set of resources matching the Wildcard pattern http://ticketmonster.apicasystem.com/ticket-monster/resources/templates/* can manually assign those “failing” resources a status of Informational using Severity Mapping. That way, the check will still pass! Other common reasons to use Severity Mappings include:

• Some specific background error that needs investigation but doesn't need to throw alerts

• Monitor 3rd party URLs without check failures

• Integrating Severity Mappings with Alerts

Examples of Severity Mapping

In the following example, any 500 error status code or 404 status code from any page on http://www.example.com will be assigned a Warning severity:

The following example utilizes regex for severity mapping:

In the following all error status codes from example.com are mapped as Fatal and all status code 500 that does not come from example.com are mapped as Warning:

Severity rules are resolved in the following order. If a URL matches two or more severities the higher severity will be used:

1. Fatal

2. Error

3. Warning

4. Information