In this lesson, we take you through the Web Application Monitoring basics: what is Web Application Monitoring, why use Web Application Monitoring, what you can monitor, and your options for monitor setup. You seasoned transaction pros may want to skip ahead to the recording/scripting lesson.

What is Web Application Monitoring?

We have a detailed description in our Knowledge Base for you to peruse. However, in a nutshell:

Web Application Monitoring is a synthetic monitor or bot that performs user actions on a website or web application at regularly scheduled intervals. The monitor uses a web browser (just like your users do) to verify that the site or application works properly and performs well.

So, pretty much, any transaction a user can make on your site using a browser, a Web Application Monitor can do the same thing at regular intervals. Web Application Monitoring checks your site around the clock seven days a week. On the chance that the transaction errors or takes too long, Uptrends' alerting system gives you a heads up.

Why monitor your web applications?

As we discussed above, a Web Application Monitor tests your web transactions to make sure everything is hunky-dory. But why would you want to monitor transactions, after all, you will notice if things go haywire, right? Sure, you will notice, eventually, but what damage is done to user confidence and reputation in the meantime?

The high cost of slow and failing web applications

If your website or service fails to operate properly, your users just switch to your competitors (lots of those out there).  Not only do they switch to a competitor, a lot of them never come back.

Failing Web Applications cost you more in future revenue than they do in immediate revenue.

For example, Akamai reported that performance alone is enough to cause 28% of users that abandoned a site never come back. After all, how confident would you be to give your personal information to a brand when their application is glitchy and slow?

By watching your transactions with Web Application Monitoring, you immediately know when there is a problem. You can jump in and fix it before it affects your users.

More can go wrong than you think

Some companies check their transactions sporadically throughout the workday, but what happens after your staff goes home at night? Sure, your peak hours may be over, but shouldn't your application work during non-peak hours? Your workday ends, but your site is working 24 hours a day. (Yo, 24-hour economy!) Many different things may go wrong that you may not notice if you're not monitoring 24/7. 24-hour checks may alert you too several problems

  • Slow loading pages and transactions due to early morning inventory updates or other backend processes. Processes that happen when you hope your users won't notice (but they do).
  • External dependencies that don't work correctly:
    • Business owners: Product inventory updates, price calculations, and ordering systems.
    • System integrations: Third-party payment providers, Google Maps integrations, SharePoint/Office365 integrations, and external calculation modules.
    • E-commerce and web analytics: User behavior trackers, Google Analytics, and advertisement systems.
    Although these third-party dependencies seem like add-ons, downtime, slow performance, or bad behavior of external systems can affect your overall performance and even break the display and behaviors of your pages.

What kind of transactions can I monitor?

A better question is, “What kind of transactions CAN’T I monitor with Web Application Monitoring.” Here are a few examples of transactions you may want to consider monitoring for performance and function.

  • Successful Logins
  • Using your sites search functionality
  • Using the calendar in a reservation system
  • Shopping cart functions: adding, removing, and selecting product options.
  • Completing forms such as order forms with connections to other services such as address verification and calculating shipping cost.
  • Successful financial transactions: connecting to merchant services, validating user input, and receiving valid server responses.

How to pick the transactions you need to monitor

Your site is probably loaded with possible user scenarios. You can't test every scenario, so how do you choose? Well, of course, you want to test the transactions that are critical to the success of your site and that your users rely on (many of them are mentioned above). Also, pick transactions that require a lot of different systems and services to come together to function and perform properly. Pick transactions that hit many parts of your systems to verify:

  • Supporting server availability and response times
  • Database access and responses: if more than one, choose transactions that hit them all. This may be your user database, product database, order procurement, user data, or any other database on which your system relies.
  • External services availability and function: For example, location and address verification, zip code lookup, inventory management systems, logistics, merchant services, or customer relationship management systems.

What data do I use for testing

We have an entire page about the pitfalls you need to avoid when monitoring your sites and services. Some of those problems are a direct result of the data you choose for testing. Be sure to read the caveats page for more information and solutions, but here are a few data-specific issues that you need to consider.

Ecommerce
When choosing products for your testing, remember that if your inventory runs out, your monitor will fail.

  • Your monitor may generate orders that consume your available inventory. These test orders may
    Preventing users from buying because of lack of availability
  • Cause auto-replenishment systems to order more product
  • Generate pick-tickets and shipping labels that result in the shipping department to package and even ship test items.
  • Purchase confirmation emails may go out filling up someone's inbox, if not your own.
  • Testing payment systems may consume available balances and generate real merchant services fees.

Reservation systems
Reservation systems and similar solutions have their own challenges.

  • Your monitor can fill up your available reservation slots blocking real users from scheduling.
  • Email confirmations fill up inboxes
  • Paid reservations may generate credit-card charges and service fees.

Login credentials

  • Choose login credentials carefully
  • Restrict the test user's permissions, and monitor the account closely for any unusual activity.
  • Protect credentials in the Uptrends Vault.
  • Log the user out at the end of the transaction to prevent login conflicts when the same user attempts to login on the next test

Analytics and Real User Monitoring

Is a Transaction Monitor always the best choice for every situation?

A transaction monitor is great for making sure everything is working together to create the outcome you expect. However, other monitor types may give you more information about your website's or service's overall performances and availabilities. For example:

  • Website performance: The Full Page Check gives you detailed information about a single page's load time. You can see the page load progression and performance for the entire page and each element.
  • Availability: Transaction monitors check your site only on five-minute increments or more, so you can accumulate a lot of downtime between transaction checks. With availability monitors, you can check availability on webpages or web services. Also, you have options for Advanced Availability Monitors for databases, email servers, FTP/SFTP servers, SSL certificates, and DNS responses.
  • APIs: Besides a basic web service uptime check, you can test your API and the APIs your system and your internal users count on (Office 365, Salesforce).

Do I have to be a computer programmer to understand and set up my web application monitors?

It certainly helps, but your skills and knowledge about your apps and services can take you a long way even if you're not a developer. However, you may find yourself in need of your developers or DevOps team for more complicated websites. Your development team may need to:

  • Replicate and adapt scripts for mirror sites in multiple languages or similar workflows and functionality.
  • Adapting scripts for upcoming site updates for deployment simultaneously with your site update schedule triggered by your continuous integration/continuous deployment (CI/CD) system.
  • Utilize the Uptrends API to leverage your monitoring setup as a valuable asset to your quality assurance system.

Up next

In the next lesson, we help you sort out your transactions and monitoring needs. Now that you've got a good idea of what you want to monitor, you're ready to record and upload your transactions with our Transaction Recorder. Once recorded, you have two options. One, you can choose to edit your scripts yourself in our handy Step Editor. (It doesn't hurt to try, and you might surprise yourself.) Two, you can upload the recording to support and our transaction gurus test and refine the script for you.