How to Handle URL Errors in a Check

Introduction

In short, Severity Mapping allows the user to assign one of four specific resulting statuses:

Information
Warning
Error
Fail

For a specific HTTP transaction receiving a specific HTTP response, for whatever purpose. Some users may not need to use Severity Mapping; others may find it indispensable.

Of the four statuses Apica monitoring provides, Severity Mappings allows you to select a specific HTTP transaction, define a set of HTTP responses (or use an asterisk for any response), then assign a specific Status to that set of circumstances. Here are some examples of Severity Mapping Uses:

Common reasons to use Severity Mappings where Blocks aren't a solution include:

Known recurring errors from a specific service or transaction that don't need to be sending out alerts

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

We'll look at some specific use cases to clarify, but first, let's look at our Blocking tools to note what Severity Mapping isn't.

Block URL

This is a way to disregard an HTTP response.

The Block URL tool is available in the Check Settings:

Blocking a URL disregards any calls made to the URL from the check's waterfall results. The most common reason to Block a URL entirely is that the performance of that URL is outside the responsibility of the Performance Team—examples: Ad Services, Facebook, Google services, 3rd party services in general.

The format for blocking is 'subdomain.domain.com' - the protocol (HTTP:// or HTTPS://, for example) should be removed, as well as any path to a specific file. Here are a few blocks as examples:

Note: Block rules can be implemented using Wildcards. such as an asterisk '*'

e.g. *block.thisDomain.com/dummyUrl/script.js*

The disadvantage of Blocking a URL is that it disregards "all" calls to the designated URL: this isn't the tool to use if you want to monitor some URLs associated with a domain but not others.

Block File Types / Block MIME Types

These can also be used to block calls by file type or by MIME type. The disadvantage is the same as Blocked URLs: these options don't allow monitoring some URLs of a given File or MIME type but disregarding others.

Alerts based on Severity

You can set alerts based on Severity, which are then sent to 'Targets' (individual users) or 'Groups' (of users) to review alerts according to the parameters you prefer.

Mapping

With Severity Mapping, you can customize how to handle error codes. Specify the URL Pattern, HTTP error status codes, and which severity you want to treat the error status codes as.

View

Item	Description	Comment

Item	Description	Comment
Severity Mapping	Method for converting errors.	`Wildcard`/ `Regex`
URL Pattern	The pattern for URLs to match.	A URL Pattern can be mapped as Regex.
Error Status Codes	The pattern for HTTP Status Codes to match.
Treat As Severity	Level of Severity to convert to.
Preserve Value	Keep and use the mapped error as a reported value.	The default behavior is not to save the result and report errors as failed checks.
Error Wildcard	Setting for Severity Wildcard.	Wildcards can be used by themselves or at the beginning or end of a URL Pattern. Unique HTTP error status code can have a wildcard at the end.

Note that the mapping only applies to URLs in the Check Result that returns an error status code (e.g., 4xx or 5xx).

Priority

Severity rules are resolved in this order

Fatal
Error
Warning
Information

If a URL matches two or more severities, the higher severity will be used.