Smart Alerts

Smart Alerts provide you with automatically generated alerting configurations, so you can receive alerts based on out-of-the-box blueprints such as website slowness, JavaScript errors, and HTTP status codes.

Select a blueprint that you would like to be alerted for, choose an arbitrary scope, for example, by geolocation, browser, OS, and so on, and the system automatically creates a tailored alert for you.

Adding an alert

  1. From the Instana user interface (UI), click Websites & mobile apps on the sidebar.
  2. Select the Websites tab.
  3. Click the name of your website and then click the Smart Alert tab.
  4. Click Create Smart Alert.
The UI workflow for creating a Smart Alert opens. This workflow uses a step-by-step process to guide you through configuring your alert.

Select trigger

Select one of the following predefined blueprints that you want to create an alert for.
Parameter Description
Custom Events Select a specific Custom Event to receive an alert when that event occurs more or less often than its usual frequency
HTTP Status Codes Select an HTTP status code to receive alerts when the status code occurs more often than usual.

When configuring a selected metric, use a threshold value based on historical data that you can modify.
JavaScript errors Select JavaScript errors to select an existing JavaScript error message that you want to be alerted for. Alternatively, you can choose the error message by providing a JavaScript message pattern by using equal, contain, starts with, or ends with a defined string.

In addition, you can select which metric is used for an alert evaluation; errors rate or errors count. Whichever metric you select, Instana automatically derives a threshold value based on the past 4 weeks of data, which can also be modified.
Slow calls Select Slow calls to receive alerts when the onLoad time or HTTP latency exceeds expectations based on historical data. The onLoad time metric exists for each page load and tracks the time until the navigation is complete. For example, when the loading indicator of the browser is stopped. The HTTP latency metric tracks the time consumed by an Ajax request. For more information about onLoad time and related metrics, see the Website monitoring FAQ.
Throughput Select Throughput to receive alerts when the expected number of page loads of your website significantly differs compared to the available historical data. A page load is defined by the retrieval of the initial HTML document and all subsequent actions until the next navigation in the browser.

You can select which metric is used for alert evaluation, such as Page Views or Sessions. For example, you can configure an alert when views are greater than the Static Daily Seasonality with a mid-range sensitivity. For this configuration, an alert is triggered when the number of page views is higher than usual.

Define scope

The scope, your current open website, is automatically selected. You can further scope the alert to a specific subset of website traffic, for example, by geolocation, browser, or user by applying the Unbounded Analytics queries.

  • Custom event (Custom event trigger only) - enter or select the custom event that you want to the alert to target.
  • Status code (HTTP status code trigger only) - Select the HTTP status code that you want the alert to target.
  • Condition and JS error message pattern (JavaScript errror trigger only) - Configure the error message pattern to that is to trigger the alert.

    You can also select to use an existing error message to get started by clicking Select from existing.

  • Filters (Optional) (all triggers) - You can define filters to receive more precise alerts.
    When you are defining a filter query, each query filter connects with the AND logic operator by default, so a beacon needs to match all the filters applied:
    • Specific pages.
    • Operating systems.
    • Geography/countries.
    • Meta: specify more metadata that you can use to annotate page views and sessions. Select one of the available keys, a predefined value, and then select an operator.

Configure Alert

The details for configuring an alert follow the same workflow for all trigger types, while the specific details for selection and input can differ. Configuring the alert involves the reviewing or updating the following details and configurations:
  • Alert Preview

    Use this visualization to see how alerts that match your configuration settings would have been triggered based on available historical metric data.

    When the alert threshold of the Smart Alert is configured, the alert preview of the dialog shows the metric, threshold, and the violations on historic data for the last 24 hours or 7 days.

  • Static threshold or Adaptive threshold
  • Metric and threshold
  • Time window
  • Violations condition and trigger
  • Grace period (optional)

Static and adaptive thresholds

When you set up a Smart Alert, you can choose to use static or adaptive thresholds as shown in the following image:

Figure 1. Threshold type
Threshold type

Static thresholds: Static thresholds do not change after the Smart Alert is created. The threshold itself can be either a simple constant value, or can account for seasonal variations that occurred in the past at the time of creation of the Smart Alert configuration. You can imagine the second case as a lookup table for every point in time of the day or week with values that were computed based on historic data. The threshold might stop being relevant after the underlying metric is changed significantly. In response, the threshold can be manually adjusted or recalculated at any point in time.

When to use static thresholds: Static thresholds work best for blueprints like Slowness or JS Errors in the following situations:
  • Irrespective of any seasonality of the underlying metric. It is undesirable for the metric to go larger than or lower than a constant value.
  • Therefore, the underlying metric is seasonal, and different thresholds exist depending on the point in time of the day or week. But these thresholds themselves don't change over time, and gradual changes to these thresholds over long periods of time is undesirable.

Adaptive thresholds: Adaptive thresholds continuously evolve and adjust themselves with new data that Instana observes. The threshold continuously accounts for seasonal changes to the underlying metric without any human intervention. For more information, see the adaptive threshold documentation.

When to use adaptive thresholds: Adaptive thresholds work best for blueprints such as Throughput or generally for the following situations:
  • The underlying metric is not seasonal. The threshold is expected to gradually change over time, but any sudden deviation from this trend is undesirable.
  • The underlying metric is seasonal and different thresholds exist for different times of the day or week. The thresholds themselves are expected to gradually change over time, but any sudden deviation from this trend is undesirable.

Metric and threshold

You can configure the alert threshold of the Smart Alert. Select a metric from the available blueprints and configure the alert threshold of the metric. The underlying metric is an aggregation of beacons that relate to the given Website. When the alert threshold of the Smart Alert is configured, the alert preview of the dialog shows the metric, threshold, and the violations on historic data for the last 24 hours or 7 days.

This step is critical when you choose the Slow calls blueprint, where the following options are available to choose from: arithmetic mean, minimum, and maximum, along with 25th, 50th, 75th, 90th, 95th, 98th, and 99th percentiles.
Note:
The metric is calculated for website beacons with a timestamp within the evaluation granularity, which is chosen as part of configuring the Time window and Violations condition and trigger.
For configuring the metric threshold use the available threshold operator, seasonality, and sensitivity options.
  • Based on your chosen blueprint, you have the Threshold operator options greater than or equal to, greater than, less than or equal to, and less than.
  • For Seasonality (static threshold), you can choose among the following static threshold types:
    • Static Threshold: Takes a constant value as the threshold.
    • Static Daily Seasonality: Uses a threshold that captures the daily repeating patterns of the metric where every day behaves roughly the same, but is different throughout the day. As an example, a website that has more traffic during the day compared to during the evening.
    • Static Weekly Seasonality: Uses a threshold that captures the weekly repeating patterns of the metric where every day of a week behaves roughly the same, but is different throughout the week. As an example, a website that has more traffic on workdays compared to the weekend.

    For Static Daily Seasonality, at least 5 days of continuous metric data is required, but 7 days of data is recommended. For Static Weekly Seasonality, at least 2 weeks of continuous historic metric data is required. The Smart Alert cannot be created when these requirements are not met.

  • For Seasonality and adaptability (adaptive threshold only), you can choose among the following settings to control how the threshold considers recurring patterns and adjusts to recent changes in data:
    • Auto: detect patterns automatically
    • Daily: use 24-hour cycles
    • None: ignore pattern
    • Weekly: use 7-day cycles
    Adjust the Adaptability (optional) setting to tune the daily or weekly seasonality to define how far outliers can deviate from the expected value before it is considered a violation.

    When using static seasonality, the expected value for each time window is derived from historical patterns and can be adjusted by using the threshold (for example, standard deviations from the norm). The adaptability setting controls how tolerant the system is to deviations from that baseline. Lower sensitivity means that fewer outliers are tolerated before triggering a violation.

    For Adaptive Threshold, at least 5 days of continuous metric data is required. If this requirement is not fulfilled, the Smart Alert can still be created. Issue detection and alerting starts working when the data requirement is met to initialize the used model.

  • For the threshold value or sensitivity (Warning or Critical)

    If you choose Static threshold, the severity level is set to Warning by default and suggests a threshold value. You can either use this recommended value or replace it with a custom value. To define an extra severity level, such as critical, select the Critical checkbox and specify the corresponding threshold value.

    When you configure sensitivity, the severity level is set to Warning by default, and you can adjust the sensitivity by using a slider. To set a separate sensitivity level for critical, select the Critical checkbox and adjust the slider.

    Adjust the sensitivity to refine the anomaly detection boundaries. As a consequence, you receive more alerts. However, if you want to receive fewer alert notifications, you can decrease the sensitivity. If you decrease the sensitivity, you extend the detection boundaries that define the expected value range of the metric. Depending on the used threshold operator, a metric that exceeds either the upper or lower detection boundary is considered a violation that might cause an alert.

Time window and violations condition and trigger

You can use a time window and violation conditions to impose more conditions on how the defined threshold on the metric is violated.

Time window: Select the period of time to set how often the threshold is checked.

Violation condition and trigger: You can select the alert condition, persistance type, and set the alert trigger:
  • Alert violation condition

    You can select Alert if violation persists over time or Alert when a specific number of users are impacted

  • If you select Alert if violation persists over time set the Peristence type

    You can select Continuous violation or Intermittent violation. Then, select when to trigger the alert. For instance, after a specific number of time windows have been violated.

  • If you select Alert when a specific number of users are impacted you receive alerts only in case a significant number or ratio of users are impacted by the defined problem.. Set the User impact evaluation method, which defines how the user impact is measured when the primary metric is violated for the amount of evaluation windows. You can select one of the following methods:
    • Aggregate across all evaluation windows, which measures the user impact as a single aggregate across the defined time window. To receive an alert, this value needs to be exceeded.
    • Calculate for each evaluation window, which measures user impact for each evaluation window individually, like any other metric. To receive an alert, the defined number of evaluation windows need to be violated in sequence for both the primary metric and the user impact.

    Then, configure the value to trigger the alert after a number of users are impacted or a percentage of users are impacted: Specify either the absolute number of users impacted, the percentage of users impacted, or both. In the latter case, you get alerted only when both limits are reached during the defined time window.

    The user impact metric requires the Instana Users API to identify authenticated users and Session API to approximate other users based on their session. Depending on the integration of these APIs, the user ID is used if provided, otherwise the session ID as a fallback.

Grace period (optional): Set how long the issue stays open after the condition clears. It will close automatically once the time is up.

Add alert channels

To send the alert notifications you can select to add an existing alert channel or create an alert channel and add that new channel.

You can add different alert channels for warning and critical severities. If a threshold value is set for both severities, all the alert channels are selected for the warning severity by default. The default severity level is warning.

If a threshold value is set only for one severity, the severity is displayed for every alert channel as the Alert Level.

To add an existing alert channels, click Add alert channels, and select the channels where you want to send the alerts.

To create and add a new alert channel, click Create alert channel. For more information about creating channels, see Alert channels.

The following image shows alert channels with both severities configured:
Figure 2. Alert channels with multiple severities
Alert channels with multiple severities
The following image shows alert channels with one severity configured:
Figure 3. Alert channels with one severity
Alert channels with one severity

Enter alert details

Enter alert details and add custom payloads.

Alert title and description

Instana suggests a default title and description based on the selected type and configuration. Optionally, you can override this custom static text or use a dynamic title by inserting variables, and selecting whether the alert triggers an incident. For more information, see Alerting.

Global custom payloads

Global custom payloads are configured in the Settings UI and are included in all notifications with matching key-value pairs. Alert-specific custom payload values override global values when there are duplicate keys.

For more information about custom payloads, see Configure Custom Payload Globally.

Alert-specific custom payloads (optional)

Configure alert-specific custom payloads to include system details or enable advanced alert routing specifically for this smart alert.

Both global custom payload and alert-specific custom payload are included in alert notifications if applicable, but the alert-specific configuration has priority over the global configuration. As a result, if using the same key, the value of the global custom payload field is overridden by the alert-specific one.

To include an additional payload that is relevant to you in alert notifications for specific alert configuration that is sent by Instana, click Add row in the Alert-specific custom payloads (optional) section.

Dynamic custom payload fields in alert-specific configuration are also supported. For example, commonly used options that you can select for Dynamic Tag, include View Name, Platform, Country, and Meta.

You can use the suggestions to select the correct key for the selected dynamic tag or add it manually.

Terraform Support

Instana enables Infrastructure as Code (IaC) capabilities by providing a Terraform resource for managing Website Smart Alerts programmatically. This capability allows DevOps and SRE teams to define, deploy, and maintain alert configurations as code. It helps improve automation and consistency across environments.

For more information about managing Website Smart Alerts by using Terraform, see Instana website alert configuration.

Thresholds and metric gaps

In the presence of gaps for a metric that is not SUM aggregated, such as latency or error-rates, Instana preserves the current alert state until the next metric value is seen. For example, this behavior is helpful when a Smart Alert is defined for a website that receives only infrequent traffic, but suffers from a persistent problem. Therefore, these periods without any website traffic do not cause repetitive alerts. However, the absence of a single website beacon for more than 3 hours causes any active alert to be closed.

Impacted users

The Impacted Users feature for website Smart Alerts helps identify widespread performance issues by tracking how many users experience a certain condition.

For each issue created by a website Smart Alert, you can now see the following details:

  • Total impacted users: The total number of users impacted while using the website where the Smart Alert is created. This count is measured from the time the alert is triggered until either the current time or the issue closing time, whichever occurs first. An Impacted User refers to any user whose browser emits a beacon that violates the alert criteria. For example, if a Smart Alert is configured for page load durations greater than 500 ms, an impacted user is any individual who experiences a page load with a duration greater than the 500 ms threshold. The user in this case is the user that is identified in the website agent. If no user is logged in, the session ID is used to identify the impacted user. For more information, see Identifying users.

  • Total users: The total number of users that were using the website. This tracking starts from the time that the alert is triggered until either the current time or the issue closing time, whichever occurs first.

  • Impact report: A detailed report shows the specific user IDs impacted for the website. This report shows a more detailed breakdown of the impacted users where each record in the table, represents a unique user for the website. For each user, the report includes their name, email address, country, subdivision, Config Label (website or mobile application name where the user was impacted), and source (web or mobile application) if reported by the agent.

Figure 4. Impacted users report
Impacted users report
Note:
Impacted user information is available only for the past 7 days. For more information, see IBM data retention policy