Destinations are where we send notifications about your New Relic data. A destination is a unique identifier for a third-party system that you use.
Destination settings contain the connection details to integrate with third-party systems and can be used across a variety of tools in New Relic.
The supported destination platforms include:
- Atlassian Jira: Available in workflows and errors inbox.
- ServiceNow: Available in workflows.
- Slack: Available in workflows and errors inbox.
- Webhook: Available in workflows.
- Email: Available in workflows.
- AWS EventBridge: Available in workflows.
- PagerDuty: Available in workflows.
For more on these and other destinations, see notification integrations.
Destination settings require specific capabilities:
- To access your settings: you need
- To modify or delete your settings: you need
Go to one.newrelic.com > Alerts & AI > Destinations. Use destinations to choose where your notifications are sent.
- Go to one.newrelic.com, click Alerts & AI, and in the left nav under Enrich and Respond, click Destinations. The destinations table shows information about the existing destinations and allows users to enable, disable, and modify.
- To add a destination, click the appropriate platform tile. To modify destination settings, click the destination row in the destinations table.
You can also configure destinations with our NerdGraph API.
Destinations have a 'status' value that indicates if we encountered issues while processing and sending events to them (see the destinations table in the above image).
Some errors, like Authentication or Authorization issues, require an update to the destination's connection details. After the update, the destination status value will be changed to "Default".
To view past notification events details, go to the Destination menu, and click the Notifications log tab.
Notifications log enable you to view the history and status of all your past notifications. Here you can view the status of any notification along with related error details and destination ticket numbers.
Filter your destination logs by destination type, sent by, and status.
If, for any reason, a notification event fails to send, the consequential error will be sent to
NrIntegrationError under the category
This is especially useful if using the
Alert conditions (policies) and workflows features. This way, you can build a condition which triggers on the event of a notification error, and a new notification can be sent elsewhere.
A step-by-step demo of adding an error notifier can be found below:
SELECT count(*)FROM NrIntegrationErrorWHERE category = 'NotificationError'
Then, you can use this condition in the query builder of the workflow configuration, where you can also define an event template.
Snoozing: In order to minimize error noise on faulty destinations, we "snooze" destinations. If, within the period of two hours, sending a notification to a specific destination returns more than ten errors, we do not try to send notifications to that destination. This is released after the two hour period.
Retrying: For specific types of errors, we retry sending the same notification. These retries are not counted in the error count for snoozing. For timeout errors, the notification is tried a total of two times, with a 1 second delay in between. For throttling errors, the notification is tried a total of three times, with a 5 second delay in between.