How to Send New Relic Alerts to Microsoft Teams (and Every Other Platform)

New Relic Alert Channels — The Multi-Platform Problem

New Relic supports Slack, Microsoft Teams, PagerDuty, and webhook as alert notification destinations. On paper, this covers the common use cases. In practice, there is a structural limitation: each notification channel is configured independently, and alert policies must be connected to each channel separately.

For an observability team that needs Slack for on-call engineers and Teams for engineering management, the workflow looks like this: create a Slack notification channel, connect alert policies to it, create a Teams notification channel, connect the same alert policies to it. Then maintain both configurations in parallel.

For teams with New Relic alert policies that have complex conditions — APM error rate thresholds, infrastructure CPU spikes, Synthetic monitor failures, browser error rate anomalies — maintaining duplicate channel connections doubles configuration complexity. A new alert condition must be connected to both channels. A policy change must be verified across both.

One Endpoint, All Platforms

SyncRivo does not receive New Relic webhooks and does not relay messages posted by bots or apps, so it is not a single alert endpoint. Keep New Relic's native Slack and Microsoft Teams destinations for the alerts themselves, and use SyncRivo to bridge the channels where on-call engineers and engineering managers discuss them.

Setup:

1. In New Relic, configure Slack and Microsoft Teams notification destinations.
2. Connect your alert policies to those destinations, filtered by severity and entity as needed: critical alerts to Slack #incidents and Teams #engineering; warning-level alerts to Slack only; infrastructure alerts to the SRE team's platform.
3. In SyncRivo, bridge the Slack incident channel and the Teams engineering channel so the human discussion flows both ways. The first bridge is typically live during onboarding, once your Slack and Teams admins approve the app.

Alert Types and Routing by Role

Configure these routes in New Relic's own alert destinations:

APM error rate breach: Route to Slack for the development team that owns the service. If the breach exceeds a critical threshold, also route to Teams for the engineering manager who handles incident escalation.

Infrastructure alert (host CPU, memory, disk): Route to Slack for the SRE or DevOps team. These are operational alerts that require technical response, not executive visibility.

Synthetic monitor failure (external endpoint down): Route to both platforms. External-facing failures have customer impact and need both the technical responder and the account/support owner notified.

NRQL alert condition (custom business metric): Route based on the metric's business significance. A revenue-related metric breach should reach Teams (where business leadership monitors); an application performance metric should reach Slack (where engineers operate).

Alert resolved: Route to the originating channel threads on all platforms. Engineers on Slack and managers on Teams both see the resolution without a manual update.

For teams expanding beyond Slack and Teams — adding Webex for a newly acquired entity, or Google Chat for a remote office — SyncRivo can bridge the human incident discussion into those platforms too; alert delivery itself still comes from New Relic's native destinations or webhooks.

For the full routing matrix, New Relic webhook payload reference, and comparison with native per-channel configuration, see the New Relic Alerts in Slack & Teams integration guide.