# New Relic + OpsGenie integration > Cut alert fatigue and get to resolution faster by routing New Relic observability data directly into OpsGenie's on-call management workflows. **Canonical page:** https://tray.ai/connectors/new-relic-opsgenie-integrations/ **New Relic connector:** https://tray.ai/connectors/new-relic-integrations/ **New Relic documentation:** https://tray.ai/documentation/connectors/service/new-relic **OpsGenie connector:** https://tray.ai/connectors/opsgenie-integrations/ **OpsGenie documentation:** https://tray.ai/documentation/connectors/service/opsgenie ## Overview New Relic and OpsGenie solve two different sides of the same problem. New Relic tells you what's wrong — application performance, infrastructure health, error rates. OpsGenie makes sure the right engineer actually hears about it and does something. When they're not connected, you get a dangerous gap: issues detected, nobody paged. Integrating them through tray.ai closes that loop, turning raw telemetry into routed, actionable alerts without anyone manually copying information between tools. Detection feeds directly into response. When New Relic and OpsGenie run independently, engineering teams end up stuck between two problems: alerts pile up in dashboards nobody's watching, and on-call engineers get paged without enough context to act. Incident details get lost moving between tools, and recovery often depends on someone manually closing the loop. Connecting them through tray.ai fixes that. New Relic anomalies automatically create OpsGenie alerts with full performance context attached. Those alerts route to the right on-call team based on service ownership. When New Relic sees recovery, OpsGenie resolves the incident. The whole cycle — detection, notification, resolution — runs without manual intervention. ## Use cases ### Automated Alert Creation from New Relic Policy Violations When a New Relic alert policy fires — high error rates, slow response times, infrastructure anomalies — tray.ai creates a matching OpsGenie alert immediately, with the affected entity, metric values, and policy name already attached. On-call engineers get something they can act on right away, not a vague ping that sends them digging through dashboards. The manual step of translating New Relic notifications into OpsGenie incidents goes away entirely. - Zero-lag alerting from New Relic detection to OpsGenie notification - Rich alert context reduces time spent investigating the root cause - Consistent alert creation removes human error from manual escalation ### Intelligent Alert Routing Based on Service Ownership Not every New Relic alert should wake up the entire engineering team. With tray.ai, you can read the affected application or service name from a New Relic alert and route the OpsGenie notification to the right team or schedule. A database throughput alert pages the data engineering on-call team. An API latency spike pages backend. The people who can actually fix the problem hear about it first — everyone else sleeps. - Fewer unnecessary pages and less alert fatigue across engineering teams - Faster resolution by immediately reaching the team with relevant expertise - Routing logic that scales as your team structure changes ### Automatic Incident Resolution When New Relic Clears Alerts When a New Relic alert condition returns to healthy, tray.ai automatically closes the corresponding OpsGenie alert. Stale open incidents stop cluttering on-call dashboards, and engineers can actually trust what they're looking at. An open OpsGenie alert means a real, ongoing problem — not something that resolved itself an hour ago. - OpsGenie incident state stays in sync with actual system health - Less manual work for on-call engineers closing resolved alerts - More accurate MTTD and MTTR reporting across both platforms ### Escalation Management for Unacknowledged New Relic Alerts If an OpsGenie alert from a New Relic event goes unacknowledged past a defined SLA window, tray.ai triggers an escalation — notifying a secondary on-call engineer, alerting a team lead in Slack, or creating a follow-up OpsGenie alert at higher severity. Critical issues don't quietly expire during off-hours or high-volume periods. Escalation logic can be customized per environment, severity, or service. - Critical incidents get a response within defined SLA windows - Missed pages during high-volume alert storms become much less likely - Custom escalation paths per team, environment, or business priority ### Enriching OpsGenie Alerts with New Relic Deployment Data When a deployment recorded in New Relic is followed by a spike in errors or latency, tray.ai creates an OpsGenie alert with deployment metadata already attached — version, team, commit details. On-call engineers know from the first notification whether a recent change is probably to blame. That cuts investigation time considerably and means less time spent reconstructing a timeline after the fact. - Connects performance degradation directly to recent deployments for faster root-cause analysis - On-call engineers have actionable context from the first notification - Reduces mean time to identification (MTTI) across post-deployment incidents ### Incident Post-Mortem Data Collection Across Both Platforms After an incident resolves in OpsGenie, tray.ai can automatically pull the relevant New Relic performance data — error traces, APDEX scores, infrastructure metrics — and compile it into a structured post-mortem report or attach it to a Jira ticket. The tedious work of correlating timestamps and metrics after every incident disappears. Teams get a complete picture of what happened, grounded in real observability data. - Post-mortem data gathering runs automatically after every incident - Post-mortems reflect actual observability metrics from New Relic, not reconstructed timelines - Creates a traceable audit trail linking incidents to performance data ### SLA Breach Alerting for Critical Application Thresholds Configure tray.ai to watch New Relic for SLA-sensitive metrics — APDEX scores, error budgets, transaction throughput — and fire high-priority OpsGenie alerts when business-critical thresholds are breached. Unlike standard New Relic alerts, these workflows can factor in business context (peak trading hours, customer tier) before setting OpsGenie priority and routing. Your most important services get the fastest response. - Business-critical SLAs get intelligent, context-aware alerting protection - Response can be differentiated based on customer impact or business context - Faster, more targeted on-call engagement reduces SLA breach risk ## Templates ### New Relic Alert to OpsGenie Incident — Automated Creation This template listens for New Relic alert policy violations via webhook and automatically creates a new OpsGenie alert with mapped severity, affected entity details, and a direct link back to the New Relic violation. It handles deduplication to prevent duplicate OpsGenie alerts from repeated New Relic notifications. Connectors used: New Relic, OpsGenie ### Auto-Resolve OpsGenie Alerts on New Relic Alert Recovery When a New Relic alert condition transitions from open to resolved, this template automatically closes the corresponding OpsGenie alert using a shared alias or incident identifier, keeping incident state synchronized without manual intervention. Connectors used: New Relic, OpsGenie ### New Relic Deployment Marker to OpsGenie Alert on Error Spike This template monitors New Relic for error rate spikes occurring within a configurable window after a deployment event and fires an OpsGenie alert with deployment metadata attached, so on-call engineers can quickly spot a potential regression. Connectors used: New Relic, OpsGenie ### OpsGenie Unacknowledged Alert Escalation with New Relic Context This template monitors OpsGenie for alerts from New Relic that remain unacknowledged past a defined SLA window and escalates them by notifying a secondary responder, with the latest New Relic metric data included in the escalation message. Connectors used: New Relic, OpsGenie ### Post-Incident New Relic Metrics Report after OpsGenie Resolution When an OpsGenie incident is marked as resolved, this template automatically queries New Relic for performance metrics covering the incident window and compiles a structured summary, ready to send to Slack or attach to a Jira ticket for post-mortem review. Connectors used: New Relic, OpsGenie ### Scheduled New Relic Health Check with OpsGenie On-Call Notification This template runs a scheduled NRQL query against New Relic to check the health of critical services and creates an OpsGenie alert if any service falls below defined thresholds — a proactive safety net that works independently of standard New Relic alerting. Connectors used: New Relic, OpsGenie ## Challenges Tray.ai solves ### Alert Volume and Noise Management New Relic can produce a high volume of alert notifications, especially in large microservices environments. Without filtering, that volume overwhelms OpsGenie and creates real alert fatigue for on-call engineers — the kind where genuinely critical events get buried and missed. **How Tray.ai helps:** tray.ai lets you build conditional logic directly into the integration workflow, filtering alerts by severity, environment, or affected entity before they reach OpsGenie. You can deduplicate using OpsGenie's alias functionality, suppress known transient issues, and enforce minimum threshold windows. Only alerts that are actually worth waking someone up make it through. ### Maintaining Bidirectional Incident State Synchronization Keeping OpsGenie incident state in sync with New Relic alert state is genuinely hard when incidents can be acknowledged or resolved from either side independently. Stale open alerts in OpsGenie mask real system health and erode engineer trust in the tooling — once people stop believing the dashboards, you have a bigger problem. **How Tray.ai helps:** tray.ai runs bidirectional webhook-driven workflows that watch for state changes in both New Relic and OpsGenie and propagate updates in both directions. New Relic clears an alert — tray.ai resolves it in OpsGenie. OpsGenie marks an alert as acknowledged — tray.ai adds a note to the New Relic incident. Both systems stay accurate without manual reconciliation. ### Mapping New Relic Alert Severity to OpsGenie Priority Levels New Relic's severity taxonomy — critical, warning, info — doesn't map cleanly to OpsGenie's five-level priority system (P1 through P5). Without a mapping layer, everything arrives in OpsGenie at the same priority, which defeats the whole point of tiered escalation policies. **How Tray.ai helps:** tray.ai's workflow logic lets you build a fully customizable severity-to-priority mapping that accounts for New Relic alert severity, the affected application's business criticality, and the environment. A critical alert on a production revenue service becomes a P1 in OpsGenie. A warning on staging becomes a P4. The mapping matches how your team actually thinks about incident priority. ### Giving On-Call Engineers Enough Context to Act An OpsGenie alert that just says a threshold was breached isn't very useful to an engineer paged at 3 AM. New Relic has the context that matters — traces, related entities, recent deployments, historical baselines — but it rarely makes it into OpsGenie notifications through native integrations. **How Tray.ai helps:** tray.ai workflows make additional New Relic API calls at alert time to pull relevant context — affected entity golden metrics, recent deployment markers, related service health — and embed it directly into the OpsGenie alert description and custom details. The engineer gets everything they need to start diagnosing in the first notification, without switching tools. ### Handling New Relic Webhook Reliability and Payload Variability New Relic webhook payloads vary in structure depending on alert channel configuration, alert type, and whether the event is opening or closing. A fragile point-to-point integration can silently drop alerts when payload structure shifts or when New Relic retries a failed delivery — which is a bad time to find out your alerting pipeline has a hole in it. **How Tray.ai helps:** tray.ai provides a resilient webhook ingestion layer with error handling, payload normalization, and retry logic built in. Workflows handle multiple New Relic payload schemas through conditional branching, so alerts process correctly regardless of structural variation. Failed deliveries are caught, logged, and retried without losing critical incident data. ## Learn more - Intelligent Integration: https://tray.ai/platform/intelligent-ipaas/ - Merlin Agent Builder: https://tray.ai/platform/merlin-agent-builder/ - Agent Gateway for MCP: https://tray.ai/platform/agent-gateway/ - Book a demo: https://tray.ai/contact/