Checks

About Checks

Checks validate your site against a set of predefined rules. This allows for

• Identify erroneous modifications that need immediate attention
• Verify your website and call to actions are working as intended
• All-round overview on every single page plus constant monitoring
• ...and much more.

It is advised to first divide your site into parts like product pages, categories and such. This allows for defining much more concise validation rules.

Checks consist of three parts

• Cluster: A set of conditions, to define a test set.
• Requirements: A list of conditions to be checked on the test set. At least one requirement is mandatory.
• Alerts: A list of people that will be notified in case one or more requirements fail. Alerts are optional.

For example think of a webshop. All its products share a common URL pattern of /products/{id}/, and for each product page, the following should hold

• It should be delivered successful
• It should contain a tracking pixel
• It should have a price greater zero

The product pages form the cluster and the three tests above form the requirements. The conditions are enclosed by IF and THEN, and the requirements are written as a list of entities.

This results in the following definition:

CHECK "Valid product pages" IS:
  IF Path Matches Regex """/products/[0-9]+/""" THEN

  REQUIREMENT "Delivered Succesful" IS:
    HTTP Status Equals 200

  REQUIREMENT "Contains Tracking Pixel" IS:
    HTML Contains "<img src=\"https://tracking.com/a-pixel.png"

  REQUIREMENT "Price > 0" IS:
    HTML Matches Regex """<span class=\"price\">\s*[1-9][0-9]*,[0-9]{2}"""

Requirements

Requirements are what brings a check to live, since they form the expectations that are validated against the test set.

Each check must have at least one requirement, but it can have arbitrary many. Note, however: The total number of requirements across all defined checks for a project or a crawl is limited to 200. For an example crawl of 10M URLs this will result in computing up to 2B testing points.

Requirements contain a name (optional), a description (optional), and conditions, they follow the basic rules for entities.

Alerts

Alerts are used to send out emails in case a check fails. Arbitrary many alerts can be defined per check.

An alert contains the following information:

• One or more email addresses - these are limited to shares of your account.
• A threshold limit which must be reached before an alert email is send.
• Whether the alert is critical or not. Critical alerts are send as soon as the threshold is reached. Non-critical alerts are send when the crawl is finished.
• An alert can be suspended. Suspended alerts will never be triggered. This can be useful while testing check configurations.

This screenshot shows an alert definition in the visual UI.

To create an alert, navigate to the Alerts section within a check. Click the Add Alert button. This will add a new alert.

Choose the email recipients by clicking the according line, and configure other options as you like. You may also choose a name and description. By clicking the Remove button right next to a rule, you can delete this alert.

In text mode, an alert is defined using the following keywords - in this order:

• SUSPENDED: If present, the alert is suspended. Can be omitted.
• MAIL TO: Followed by a list of email address, separated by comma. An email address is either a simple address or in the format "name" <address>
• WITH THRESHOLD: Followed by either an integer number to define an absolute threshold or a floating point number and a percent sign (%) to define a proportional threshold.
• CRITICAL: If present, the alert is critical. Can be omitted.

This is an example of a complete alert definition:

ALERT IS:
  SUSPENDED
  MAIL TO "Me" <account-admin@example.com>, "Development" <dev@example.com>
  WITH THRESHOLD 7.5%
  CRITICAL