Create or rename an alert policy

An alert policy can apply to one or more New Relic products (targets or entities). It can also contain one or more alert conditions and one or more notification channels. You can make an alert policy as simple or as complex as your organization requires.

Admins, Owner, or add-on managers: The basic setup process is the same, regardless of which New Relic product (APM, Browser, etc.) uses the alert policy. The types of metrics and thresholds for alert conditions will vary depending on the target.

Best practices for naming alert policies

New Relic recommends three common patterns and practices for structuring and naming alert policies:

  • Targets or resources in your architecture that have people responsible for their well being
  • Teams that are responsible for part of the architecture
  • Individual policies for specific users
Policies organized by... Comments
Architecture

Targets or resources in your organization may have different people responsible for their well-being. Common segments may include the environment type (production, staging, integration, development) or the target or resource type (app server code, client-side code, databases, hosts, etc.).

To make these types of alert policies easier to identify, you can give them names based on your architecture. For example:

  • Product A website (production)
  • Product B website (staging)
  • Mobile product app (iOS)
  • Hosts (production)
  • Databases (production)
Teams Specific teams may be responsible for parts of your architecture. For example, you may want to name their alert policy Team: Site engineering, Team: Website development, etc.
Individuals

Alert policies set up for specific individuals may be useful when they want to personally keep an eye on a particular resource or metric. This provides them the freedom to add and remove conditions as well as adjust thresholds whenever they want, without having to communicate those changes to others.

To make these types of alert policies easier to identify, you can include the person's name in the alert policy; for example, User: John Doe's metrics, User: Jane Doe (production), etc.

Create an alert policy

Admins or Owner

As part of the alert policy workflow in New Relic Alerts, start by giving the policy a meaningful name:

  1. Go to alerts.newrelic.com > Alert policies.
  2. From the Alert policies index, select New alert policy.
  3. Type a meaningful name for the policy (maximum 64 characters), and select Save.

You can continue from here to define the alert conditions and assign one or more notification channels. If you decide to continue later, select the alert policy's name from the Alert policies index.

Change a policy's name

Admins or Owner: For your convenience, New Relic Alerts allows you to use the same name for different policies, conditions, and notification channels. If you want to use unique names, review or search the index before adding or changing a name.

Alerts v3: Alert policy name
alerts.newrelic.com > Alert policies > (select a policy): To give a different, meaningful name, mouse over the selected policy's existing name, and then select the edit (pencil) icon.

To rename an existing alert policy:

  1. Go to alerts.newrelic.com > Alert policies > (select a policy).
  2. Mouse over the policy's name, and select the edit icon.
  3. Type a meaningful name for the policy (maximum 64 characters), and select Save.

New Relic Alerts automatically updates any associated alert conditions and notification channels for the policy.

View existing policies

The New Relic Alerts index lists alert policies in alphabetical order. To view or search for existing alert policies:

  1. Go to alerts.newrelic.com > Alert policies.
  2. Use the search box, sort any column, or scroll the list.
  3. To view detailed information, select the policy's name.

To view policy and condition information for a specific entity, select the Settings > Alert conditions page from the entity's New Relic product UI.

Use legacy alerting system

This applies only to the legacy alerting system, not New Relic Alerts.

New Relic's legacy alerting system uses a different workflow in the user interface. You can create individual policies for applications, hosts, and key transactions. You can also create groups with common alert conditions.

Alerts menu for basic alerting system
Alerts menu for legacy alerting system.
Add and update policies in legacy alerting system

This applies only to the legacy alerting system, not New Relic Alerts.

screen app policy edit.png
rpm.newrelic.com > (select a product) > Alerts > Application policies: Use the Application alert policies page to manage new or existing alert policies for apps, or use the default policy.

To use the legacy alerting system to add, update, or delete alert policies for apps, hosts, or key transactions:

  1. From rpm.newrelic.com, select a product (APM, Browser, etc.), then select Alerts.
  2. From the Alerts menu, select the policy type as available: Applications, Key transactions, or Servers.
  3. Follow the workflow in the UI to create policies, then add apps, key transactions, or hosts to them.
  4. Use the threshold sliders to add required Critical (red) and optional Caution (yellow) values.

If you enable Downtime app alerting, provide the number of minutes to wait before sending an alert, or accept the default value. If you have not set a URL for the New Relic pingers to poll for availability, an error message will appear under the Downtime alert status indicator on the Application policies page in New Relic's legacy alerting system.

To test alert conditions for your policy: Lower the threshold setting to a value that should cause an incident, and wait the appropriate interval. Then look for a new incident on the entity's Recent events list and for any alert notifications you have set up (such as email). When finished testing, return the threshold setting to its original value.

Use default policy for legacy alerting

This applies only to the legacy alerting system, not New Relic Alerts.

Default policies ensure everything has an alert policy associated with it. When a new application, key transaction, or host is added, it is associated with the default alert policy. When a policy is deleted, any applications, key transactions, or hosts still associated with it revert to the default policy.

Default policies cannot be deleted. However, you can select the option to disable them in the user interface.

View policies in legacy alerting system

This applies only to the legacy alerting system, not New Relic Alerts.

To view alert policies:

  1. From rpm.newrelic.com, select a product (APM, Browser, etc.), then select Alerts.
  2. From the Alerts menu, select the policy type as available: Applications, Key transactions, or Servers.
  3. To locate a specify policy, navigate through the policies by page, or use the search bar to filter by name.

From the selected legacy policy type's index, the default policy appears first with a different background color. Each policy pane contains a title bar and three columns that summarize:

  • The current health status for applications, hosts, or key transactions associated with the policy (left column)
  • Alert conditions specified for the policy (middle column)
  • Channels that receive alert notifications for the policy, and your notification preferences for the policy, if applicable (right column)

The legacy policies index includes additional functions.

If you want to... Do this...
View the name of a policy's app, host, or key transaction

Mouse over its color-coded health status indicator.

To go directly to the associated app, host, or key transaction, select the color bar for its name in the policy. Then, to return to the Alert policies index, use your browser's Back function.

View information about alert notification types and their destinations Mouse over the policy's notification channel icons.
Enable or disable availability monitoring for downtime alerts

From the middle column of the alert policy, select On or Off.

For application policies, an error message appears if ping URLs are not specified for downtime alerts.

Remove unused alert policies From the alert policies index for applications, key transactions, or hosts, select Delete all empty policies.
View legacy alerting violations

This applies only to the legacy alerting system, not New Relic Alerts.

When an event passes the alert condition's threshold and triggers an alert, the alert summary information appears on Recent events list for your New Relic APM applications index and the selected app's Overview page. To filter the Recent events list to a specific type of event, select the corresponding icon at the top of the list.

For details about an alert, including history and charts, select the corresponding link. From the details page you can acknowledge that you received the alert notification.

You can also view details about alerts, errors, and deployments from the New Relic user interface by selecting Alerts > Alert history or from New Relic APM by selecting an app and then selecting Events.

To view detailed information about a specific alert, select the alert's name. The alert details include:

  • The alert status, with a link to the associated app's performance during the alert
  • A list of events that occurred during this alert
  • Charts showing the average response time, Apdex score, throughput, and error rate percentages during this alert

To view a list of all alerts: From rpm.newrelic.com, select Alerts > Alert history.

Disable or delete policies in legacy alerting system

This applies only to the legacy alerting system, not New Relic Alerts.

New Relic does not allow applications, hosts, or key transactions to be entirely removed from all legacy policies. To disable alerting for them, use any of these options:

  • Select the entity (app, host, or key transaction) you do not want to have alerts, then assign it to an existing disabled policy.
  • Create a new policy but do not enable it. Then assign the target to it.
  • Disable the policy containing the entity: Mouse over the policy's title, then select Disable this policy.

To disable alerts for a target application, host, or key transaction, associate it with a disabled alert policy.

  1. From rpm.newrelic.com, select Alerts > (selected policy type).
  2. Disable an existing policy or create a disabled policy to hold targets you do not want reporting.
  3. Select the policy's title to open it in edit mode.
  4. Select Assign (target).
  5. From Assign to policies, select the items to associate with the inactive policy.
  6. If the current policy is not the inactive one, select the inactive policy from the Choose destination dropdown.
  7. Select Assign.

To delete legacy policies, mouse over the individual policy's title bar and select the delete [trash can icon], or select the option in the user interface to Delete all empty policies. If you delete a legacy policy entirely, anything still assigned to it will be reassigned to the default policy. You cannot delete the default policy in the legacy alerting system.

For more help

Additional documentation resources include:

  • New Relic Alerts (getting started with New Relic Alerts and learning how to get the most out of its operational potential with the New Relic products you use)
  • Best practices for alert policies (defining policies based on your architecture or your staffing requirements, deciding how many alert policies and conditions you may need, selecting effective channels for alert notifications)
  • REST API calls with New Relic Alerts (using New Relic's REST API (v2) and API Explorer to add, update, delete, or list New Relic Alerts data for your account)

Recommendations for learning more: