tip This documentation is for the old interface of AlertSite. If you use the new interface (AlertSite UXM), please see Performance Alerts.

Performance Alerts


Response time performance, not just availability, is vital for mission-critical sites and applications. The Performance Alerts feature allows the user to receive notifications when devices are not responding within configured thresholds. It is not tied to availability and uptime, but to response time metrics. Knowledge of how to configure devices in the AlertSite console is a prerequisite for using this guide.


There are two measurement styles, dynamic or static.

  • Dynamic thresholds compare the current response time to the average response time over a specified time period (10 minutes to 24 hours) as a percentage of the average over the past number of days (1 day to 7 days).
  • Static thresholds compare the current response time to the average response time over a particular time period (10 minutes to 24 hours).

The thresholds apply on a per-location basis. The number of monitoring locations is also taken into account, either as a specific number or percentage. How to configure each feature is described below.

Configuration Options

To configure performance alerts for a device:

  • In the top menu, click Configure, then select Sites, Transactions or APIs depending on your device type.
  • Click the device in the list.
  • Click the Performance Alerts button in the upper right corner.

Performance Alerts button

If the Site Plan for the device does not support Performance Alerts, this button is not displayed.

The Performance Alerts configuration screen looks like this:

Performance Alerts configuration screen

For multi-step transactions and API devices, you can set different performance alerts for each step.

For transactions with ContentViews, you can also set different alerts for each ContentView. Say, for example, a transaction has three ContentViews as shown on the Manage Transaction page:

ContentViews in a transaction

The Performance Alert screen will show the main transaction along with a list of ContentViews that you can configure Performance Alerts on:

Performance Alerts configuration for a transaction with ContentViews

Enable/Disable Performance Alert Processing

This field is disabled by default. Select Enable from the drop-down menu under Enable/Disable Performance Alert processing, otherwise the notifications will not be sent.

Select Measurement for Averaging

The metrics available for Performance Alerts will vary depending on the device's configuration. All available metrics are as follows:

Fullpage Response Time Devices with Fullpage Option (Default for devices with Fullpage Option)
Response Time All Devices (Default for devices without Fullpage Option)
DNS Time All Devices
Connect Time All Devices
First Byte All Devices
Content Download All Devices
First Paint DéjàClick Firefox transactions with Perceived User Experience enabled
Above the Fold DéjàClick Firefox transactions with Perceived User Experience enabled
DOM Load DéjàClick Firefox transactions
Page Load DéjàClick transactions

The following image shows performance alert configuration for the entire transaction, with thresholds for the Fullpage Response Time metric.

Performance alert for Fullpage Response Time

The following image shows performance thresholds for the Above the Fold metric of the first step in the transaction.

Performance alert for Above the Fold metric

Please note that averaging is done on a per-location basis. This affects the sample size for averaging when monitoring with rotated locations.
See Additional Considerations below.

Configure Performance Alert Thresholds

There are two methods for configuring thresholds: Dynamic or Static.


If selecting the Dynamic radio button, choose the time period (from 10 minutes to 24 hours) in which to compare the current response time to the response time average, based on the percentage, over the last 1 to 7 days.

For example, say the Dynamic section is configured as follows:

  • Current response time average for the last 1 hour is equal to or greater than
    • 60% for error
    • 40% for warning
  • Over the historical average response time during the last 1 day
  • Detected from 1 monitoring location

Say the average response time over the past hour is 12 seconds, and over the last day, the average response time was 10 seconds. No Performance Alert notification would be sent because the 2-second difference is only 20%, which is lower than either the warning (40%) or error (60%) thresholds.

Now, say the web site's response time increased significantly for unknown reasons. The site isn't down, but response time averaged 14 seconds over the last hour. The additional 4 seconds is 40% over the average during the previous 24 hours; this would trigger a warning alert. If the response time for the last hour increased to an average of 16 seconds, that 6-second increase would equal 60% and trigger a performance error alert.

Note that if the increase in response time was only being detected at 1 location and the threshold was configured to require 2 locations to detect the increase in response time, no alert would be sent.


The Static method is more straightforward. Consider the Static section configured as follows:

  • Current response time average for the last 1 hour is equal to or greater than
    • 16 seconds for error
    • 14 seconds for warning
  • Detected from 50% of the monitoring locations (assume for this example that the site has 6 monitoring locations and a 5-minute monitoring interval).

Assume the response time over the last hour is 11 seconds. No warning (14 seconds) or error (16 seconds) threshold was reached. If 1 location reported an average of 14 seconds over the last hour, no warning alert would be sent. If 3 or more locations each reported an average of 14 seconds over the last hour, a warning alert would be sent. If the per-location average over the last hour was 16 seconds or longer from 3 or more locations, it would trigger an error alert.

Back to top

Configure Notifier

In order to receive Performance Alert notification, a notifier must be configured to receive the alerts. You can modify an existing notifier or create a new one for the purpose.


  • It is recommended to use E-Mail or Text Message for Performance Alerts since they are low-level warnings about web site performance, not an indication that your site is down. You may not want to be awakened in the middle of the night for a performance alert.
  • Performance alerts do not follow blackout rules set for devices and notifiers, and will continue to be sent during blackout periods.

Bring up the Configure Notifiers screen by clicking on Notifiers in the Control Menu. To create a new notifier, click the Add Notifier button in the upper right of the console.

In the Configure Notifier Type/Description section:

  • Enter a Description.
  • Leave Send a(n) as E-mail or select E-mail to wireless device (cell phone, pager, Blackberry, etc.)
  • Enter an email address in the To field.

If this is going to be a Performance Alert-specific notifier, deselect the check box labeled Enable availability notifications in the Configure Standard (Availability) Notifications section.

Under the Configure Performance Alerts section:

  • Check the box labeled Enable performance alerts.
  • Select errors only or warnings and errors from the Select performance alerts of type drop down.
  • Check the Repeat successive performance alerts box if you want to continue to receive Performance Alerts, otherwise leave it blank.

Notifier configuration for performance alerts

To configure an existing notifier, click on the notifier in the Notification Method column, then complete the Configure Performance Alerts section as described above.

Additional Considerations

When monitoring with rotated locations, consider the monitoring interval and number of locations you are monitoring with when setting the Response Time Average selection. For example, say your device is configured as follows:

  • 12 monitoring locations
  • rotating 1 location per interval
  • 5-minute monitoring interval

and the Performance Alert for the device is configured with:

  • Fullpage Response Time measurement for averaging
  • Static Response Time Averaging over 10 minutes
  • 5 seconds for error
  • 3 seconds for warning
  • 1 location exceeding the threshold triggers alert

With this setup, there would be 12 tests in an hour, and each location runs only once per hour. Because Performance Alerts averaging is done on a per-location basis, selecting 10 minutes for averaging may not be an adequate sample size. As soon as any location exceeded the alert threshold during the 10-minute averaging interval, you would receive a Performance Alert notification.

Consider what sample size is appropriate for your purposes. If you're looking at trending as opposed to a single event, you may want to use Last 6 Hours for Performance Alert averaging with a device configuration similar to the above. That way, each location will run approximately 6 tests, a more useful sample size to determine performance trends.

Plugging in some numbers:

  • Over the last 6 hours, all locations except Los Angeles ran 6 tests and returned Fullpage Response Time values of 3 seconds or less
  • Over the last 6 hours, Los Angeles returned the following values for its 6 tests:
    • 1.6789
    • 4.4532
    • 2.0051
    • 3.1008
    • 1.9855
    • 4.9982
  • The average Fullpage Response Time is 3.03695 (total 16.2217 seconds / 6) which is over the 3 second warning threshold
  • Notification is issued with a WARN designation showing Los Angeles averaged 3.037 seconds over the last 6 hours

Note that if another location exceeded the Fullpage Response Time threshold over the same 6 hours, it would be listed in the same Performance Alert notification.

Back to top

© 2016 SmartBear Software --
Syndicate this site RSSATOM