On this page:

Related pages:

This topic introduces you to the automated alert and response capabilities in AppDynamics.

About Alerts and Responses in AppDynamics

AppDynamics can generate notifications or take other types of actions based on conditions or events you configure. Using the alert and respond feature, you can find out about problems as they happen, or even before they happen when you define alerts on warning conditions.

In AppDynamics, policies serve as the central configuration artifact for the alert and respond feature. A policy ties one or more conditions or events to the measures to take when the condition is met or event happens.

The condition or event is defined by a health rule, while the steps to take are encapsulated by an action. AppDynamics comes with several preconfigured health rules, giving you a head start and examples for you to following when creating your own. For example, built-in health rules test for whether the "Business Transaction error rate is much higher than normal" or "CLR Garbage Collection Time is too high". See Default Health Rules for more. 

Actions automate the response to an event, such as the sending of an alert or performing diagnostic or remediation actions. See Alert and Respond API to learn how to create custom URLs for notifications.

While policies generate real-time responses to detected conditions, email digests generate email messages about the conditions and events in a system on a scheduled basis. 

Notification actions that use email or SMS and email digests require that the SMTP server be configured for the controller. See Enable an Email Server.

Alert and Respond Policy Structure

A policy matches evaluated event triggers with actions to be taken in response to those triggers.

What You Can Do with Alert and Respond

The following use cases illustrate the types of things you can do with the alert and respond feature in AppDynamics. While not an exhaustive list, it should give you an idea about the length and breadth of the feature. 

Watch the Video

<style type="text/css">.vidyard_player{width: 600px; }.vidyard_player > span{max-width: 600px !important; max-height: 360px!important;margin-left:0!important;}.innerContainer{position: relative; display: block; width: 100% !important; height: 0; }</style><script type="text/javascript" id="vidyard_embed_code_QmMPQGDaJgCbHxGdvq7fYQ" src="//play.vidyard.com/QmMPQGDaJgCbHxGdvq7fYQ.js?v=3.1.1&type=inline&second=90"></script>

Click this link to see a full screen version of the video, Configuring Actions and Policies.

Alert and Respond across the Platform

The alert and respond features work across AppDynamics products, including Infrastructure Visibility, Analytics, EUM, and Application Monitoring. Unless otherwise noted, this documentation describes the features in the context of Application Monitoring, which, by its nature, offers the broadest range of configuration and use case options. Certain features as described may not apply to other AppDynamics products. 

Additional usage notes include:

Scope and Access

Typically different types of users with different types of roles set up and use different alert and respond features.

Email templates, HTTP request templates, and Email/SMS configuration are account-level features. The scope of these features, once set up, is the entire AppDynamics account. The items created at the account level are available to all the applications in that account. Account-level items are created and managed by users who have account-level roles that include permissions to create them.

By default these roles belong to the account owner and could be granted to an account administrator. Custom roles could also be created that include some of these permissions. For example, an account owner could create an email template manager role that could be assigned to other users to give them the ability to create and modify email templates.

Policies, health rules, actions and email digests are application-level or tier-level features. The scope of these features is the application or tier in which they were created. Only roles with application-level or tier-level permissions are required to create and manage these items.

See the Application- and Tier-Level Permissions section in Roles and Permissions for details about these permissions.