Transaction Check Basics

In this brief article, we will cover how to setup and make the best use of a Transaction Check. This tool allows you to monitor transactions on your site, verifying the path toward a specific user objective is always working.

Transaction Check Basics

To add a new Transaction Check, click “Monitoring” followed by “Add Check”.

Every goal has an intended path, and it’s essential that nothing breaks along the way. You may have defined specific goals within your Analytics, using particular taxonomies to identify user groups. Testing those paths and groups uncovers any elements that inadvertently contribute to bounce rate, lost revenue or a decrease in signups.

Webmasters utilize transaction checks to simulate a particular user experience that tests every element along a funnel’s path.

Advanced Transaction Check: Check Uptime Ticket Request Form

In this article, we will create a Transaction Check that will test the request form on Uptime.com to see that it’s working.

Our Transaction Check will perform the following steps:

  1. Go to URL https://support.uptime.com/hc/en-us/requests/new
  2. It will wait for #new_request to exist
  3. It will fill in #request_anonymous_request_email with test@test.com
  4. It will fill in #request_subject with Test Subject Line
  5. It will fill in #request_description with Test Description
  6. It will submit form #new_request
  7. Wait for #.notification.notification-notice to exist
  8. Finally, it will verify the element .notification.notification-notice exists

These steps will fill in the contact form, then submit it and verify the test worked by looking for a specific element that appears on the page after a contact request is made.

For a detailed breakdown of each command/verification, please visit the Field Explanation support article.

 

The green “Run Test” button will start a Transaction Check that goes through each step that we have defined. It records the average page load time, and other technical details, when it performs a given check. Once complete, we can download the HTML of each URL and show details. Details include Post URL, status code, cookies, response headers and request headers.

Assuming everything we entered checks out, we will see values that define the average load time for all URLs being tracked within this test alongside a new option: View Browser Console. The Browser Console provides a snapshot of the number of requests per browser, and it’s useful for spotting redirects and other requests made by the server that increase load times.

Failed Checks

If a Transaction Check fails, we will see a notification in red that informs us in brief detail of the error.

It appears whoever created this test didn’t accurately check the element in step 2. Uptime will catch this error and identify the step where our Transaction Check failed. We can correct our mistake with the proper element name, then run a new test to confirm it works before we push it live. Click Step 2 to edit the step and replace the incorrect element with the proper text. Click on the green “Run Test” button to confirm it’s working.

Typically, the best way to correct an error is to inspect each step carefully and be sure you’re using the proper URL, text, element ID, name or CSS selector. Check syntax too.

Once we have corrected our errors, and the test is working, we finalize and deploy it by clicking the blue "Save" button.

Finalizing the Transaction Check

Before a Transaction Check can go live, it must have:

  • Name
  • Defined interval
  • Contacts - Choose a specific list of contacts that should be notified
  • Locations of probe servers from which to test

Once our check has been tested, and the above requirements fulfilled, we’re ready to save our Transaction Check. At the intervals we defined, a simulated check will run along the path we’ve set and alert us, and other contacts we may have defined, by the preferred contact method when a step fails its check.

Defining Commands and Validators

Now that we have seen a Transaction Check in action, here is a list of all potential check steps not covered in the example above. For definitions of this terminology, please visit our Field Explanation support article.

Step Commands

  • Authentication & Settings
  • Click Element
  • Check Checkbox/Radio Button
  • Uncheck Checkbox/Radio Button
  • Wait for Element To Contain
  • Wait 1 Second

 Validations

  • HTTP Status Code Should Be
  • URL Should Contain
  • URL Should Not Contain
  • Title Should Contain
  • Title Should Not Contain
  • Element Should Not Exist
  • Element Should Contain
  • Element Should Not Contain
  • Checkbox/Radio Button Should Be Checked
  • Checkbox/Radio Button Should Not Be Checked