Integrations

ServiceNow New Relic Integration Guide

intermediateAPI Key in headerNew Relic

The ServiceNow New Relic integration enables IT operations teams to automatically create incidents from New Relic performance alerts, maintaining service health visibility directly within their ITSM workflow. This integration is essential for DevOps and SRE teams who need to bridge application performance monitoring with incident management processes. The integration supports bidirectional data synchronization, allowing New Relic alerts to trigger ServiceNow incident creation while enabling ServiceNow to push resolution status and notes back to New Relic. The primary automation pattern uses New Relic webhook notifications combined with ServiceNow's Scripted REST API endpoints to trigger incident creation, with additional Flow Designer workflows handling ticket updates and APM data enrichment within the Incident Management module.

Prerequisites

  • ServiceNow Quebec or later with Integration Hub Professional license
  • New Relic Pro or Enterprise subscription with alert configuration access
  • admin_role privileges in ServiceNow for creating REST API endpoints
  • itil role for configuring incident workflows and assignment rules
  • New Relic account with API key generation permissions
  • Outbound internet connectivity from ServiceNow instance to New Relic APIs
  • Flow Designer activation and Flow Designer role for building automation workflows

Architecture Overview

This integration leverages ServiceNow's native REST API capabilities and Flow Designer workflows rather than a dedicated Integration Hub spoke, providing maximum customization flexibility for New Relic webhook processing. Authentication is established using New Relic API keys stored in ServiceNow Connection & Credential Alias records, enabling secure outbound calls to New Relic's REST API for incident enrichment and status updates. The data flow is primarily inbound-triggered, with New Relic sending webhook notifications to ServiceNow Scripted REST API endpoints when alert conditions are met, followed by bidirectional synchronization for incident status updates. A MID Server is not required since all communication occurs over HTTPS REST APIs between cloud endpoints, though one may be beneficial for organizations with strict network policies requiring traffic inspection. New Relic enforces rate limits of 1000 API calls per minute per account, which should be considered when designing high-frequency update patterns or bulk data synchronization workflows.

Sourdough
Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher
Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview
Tasks
CMDB
API
Metrics
Monitor
Internals
Instance:sourdoughdev·Version:Yokohama
Instance StateONLINE
System StatusFully Operational
Session Timeout90 minutes
Logged-In Sessions2 (20 active)
Build Nameyokohama-12-18-2024_p1
IP Address10.159.128.43
Instance HealthHealth Score: 90%
🔥 5dSourdough (Chrome Plugin)Dark Mode

Implementation Steps

1

Generate New Relic API key and create ServiceNow credential

Log into your New Relic account and navigate to Account Settings > API Keys to generate a new User API key with full account access. Copy this API key value as you'll need it immediately for ServiceNow configuration. In ServiceNow, navigate to Connections & Credentials > Credentials and create a new API Key Credential record with the name 'New Relic API Credential'. Paste the copied API key into the API key field and set the credential to be available for REST Message authentication. Verify the credential is saved successfully and note its sys_id for use in subsequent REST Message configurations.

2

Create REST Message for New Relic API communication

Navigate to System Web Services > Outbound > REST Message and create a new REST Message named 'New Relic Integration API'. Set the endpoint URL to 'https://api.newrelic.com' and configure authentication to use the credential created in step 1. Add a default HTTP header 'Api-Key' with value '${credential.api_key}' and set Content-Type to 'application/json'. Create HTTP methods for common operations like 'Get Incident Details', 'Update Incident Status', and 'Get Application Performance Data' with appropriate endpoint paths and HTTP verbs. Test the connection using the Test functionality to ensure authentication succeeds and you receive valid responses from New Relic's API.

ServiceNow Script
var rm = new sn_ws.RESTMessageV2('New Relic Integration API', 'Get Application Performance Data');
rm.setStringParameterNoEscape('app_id', current.u_application_id);
rm.setRequestHeader('Api-Key', gs.getProperty('new_relic.api_key'));
var response = rm.execute();
var responseBody = response.getBody();
var httpStatus = response.getStatusCode();
if (httpStatus == 200) {
    var perfData = JSON.parse(responseBody);
    current.u_apm_data = JSON.stringify(perfData.application);
    current.update();
}
3

Create Scripted REST API endpoint for New Relic webhook consumption

Navigate to System Web Services > Scripted Web Services > Scripted REST APIs and create a new API named 'New Relic Webhook Handler' with base API path '/api/x_custom/newrelic'. Add a new resource with HTTP method POST, path '/incident', and name 'Create Incident from Alert'. Configure the script to parse incoming New Relic webhook JSON payload and extract critical incident data like alert policy name, severity, application name, and violation details. Implement proper error handling to return appropriate HTTP status codes and ensure webhook delivery acknowledgment. Set up logging using gs.info() to track successful webhook processing and gs.error() for debugging payload parsing issues.

ServiceNow Script
(function process(request, response) {
    try {
        var payload = JSON.parse(request.body.data);
        var alert = payload.current_state;
        
        var incident = new GlideRecord('incident');
        incident.initialize();
        incident.short_description = alert.policy_name + ': ' + alert.condition_name;
        incident.description = 'New Relic Alert: ' + alert.details;
        incident.urgency = (alert.severity === 'critical') ? 1 : 2;
        incident.impact = 2;
        incident.u_alert_id = alert.incident_id;
        incident.u_source = 'New Relic';
        
        var sys_id = incident.insert();
        
        response.setStatus(201);
        response.setHeader('Content-Type', 'application/json');
        response.getStreamWriter().writeString(JSON.stringify({incident_id: sys_id, status: 'created'}));
        
        gs.info('New Relic incident created: ' + sys_id);
    } catch (e) {
        gs.error('Error processing New Relic webhook: ' + e.message);
        response.setStatus(400);
        response.getStreamWriter().writeString(JSON.stringify({error: e.message}));
    }
})(request, response);
4

Configure New Relic notification channel and alert policy

In New Relic, navigate to Alerts & AI > Notification channels and create a new Webhook notification channel named 'ServiceNow Integration'. Set the webhook URL to your ServiceNow instance URL followed by the Scripted REST API path (e.g., 'https://yourinstance.service-now.com/api/x_custom/newrelic/incident'). Configure webhook authentication using basic authentication with a ServiceNow integration user account that has sufficient privileges to create incidents. Set the payload type to JSON and configure custom headers if required by your ServiceNow security policies. Test the notification channel to ensure webhook delivery succeeds and creates a test incident in ServiceNow.

5

Build Flow Designer workflow for incident enrichment

Navigate to Process Automation > Flow Designer and create a new flow named 'Enrich New Relic Incidents with APM Data' with trigger 'Record Updated' on the Incident table. Add conditions to filter for incidents where the source is 'New Relic' and u_alert_id is not empty. Create a REST step using the New Relic REST Message to fetch additional application performance metrics, infrastructure data, and recent deployment information. Parse the API response and populate custom fields on the incident record with relevant performance data like response times, throughput, error rates, and Apdex scores. Implement error handling to gracefully manage API failures and ensure the incident processing continues even if enrichment data is unavailable.

ServiceNow Script
var enrichmentData = {
    'u_response_time': perfData.application.response_time,
    'u_throughput': perfData.application.throughput,
    'u_error_rate': perfData.application.error_rate,
    'u_apdex_score': perfData.application.apdex_target
};

for (var field in enrichmentData) {
    if (enrichmentData[field] !== undefined) {
        current[field] = enrichmentData[field];
    }
}
current.update();
6

Create bidirectional sync workflow for incident status updates

Create another Flow Designer workflow named 'Sync ServiceNow Incident Status to New Relic' triggered by incident state changes. Add conditions to process only incidents originating from New Relic alerts that have valid u_alert_id values. Configure REST steps to call New Relic's incident API and update the corresponding alert incident status when ServiceNow incidents are resolved, closed, or reopened. Map ServiceNow incident states to appropriate New Relic incident states (e.g., ServiceNow 'Resolved' to New Relic 'Closed', ServiceNow 'In Progress' to New Relic 'Acknowledged'). Include work notes synchronization to maintain audit trails in both systems and implement retry logic for failed API calls using Flow Designer's error handling capabilities.

ServiceNow Script
var stateMapping = {
    '6': 'closed',     // ServiceNow Resolved -> New Relic Closed
    '7': 'closed',     // ServiceNow Closed -> New Relic Closed
    '2': 'acknowledged' // ServiceNow In Progress -> New Relic Acknowledged
};

var newRelicStatus = stateMapping[current.state.toString()];
if (newRelicStatus && !gs.nil(current.u_alert_id)) {
    var rm = new sn_ws.RESTMessageV2('New Relic Integration API', 'Update Incident Status');
    rm.setStringParameterNoEscape('incident_id', current.u_alert_id);
    rm.setRequestBody(JSON.stringify({status: newRelicStatus, notes: current.work_notes}));
    var response = rm.execute();
}
7

Configure custom incident fields for New Relic data

Navigate to System Definition > Tables and locate the Incident table to add custom fields for storing New Relic-specific data. Create fields like 'u_alert_id' (String) for New Relic incident correlation, 'u_application_name' (String) for the monitored application, 'u_apm_data' (JSON) for performance metrics, and 'u_source' (Choice) to identify New Relic-originated incidents. Add these fields to the incident form layout by navigating to System UI > Forms and editing the Incident form. Create a dedicated form section titled 'New Relic Information' to group these fields logically and make them easily accessible to support teams. Update the incident list view to include key New Relic fields for better visibility and filtering capabilities.

8

Test integration end-to-end and validate data flow

Create a test alert condition in New Relic that will trigger quickly, such as a response time threshold slightly below current performance levels. Monitor the ServiceNow system logs and verify that webhook notifications are received and processed correctly by checking the Scripted REST API execution logs. Verify that incidents are created with proper field population, enrichment workflows execute successfully, and APM data is populated in custom fields. Test the bidirectional sync by manually updating incident status in ServiceNow and confirming that corresponding changes appear in New Relic's incident timeline. Document any performance issues, error patterns, or field mapping inconsistencies discovered during testing for future optimization.

ServiceNow Script
// Test webhook processing
gs.info('Testing New Relic webhook integration');
var testPayload = {
    current_state: {
        policy_name: 'Test Policy',
        condition_name: 'Response Time Alert',
        severity: 'critical',
        incident_id: 'test_123',
        details: 'Response time exceeded 2 seconds'
    }
};

// Verify incident creation and field population
var testIncident = new GlideRecord('incident');
if (testIncident.get('u_alert_id', 'test_123')) {
    gs.info('Test incident found with sys_id: ' + testIncident.sys_id);
} else {
    gs.error('Test incident not created properly');
}

Common Use Cases

Automatic incident creation from APM alerts

New Relic monitors application performance metrics like response time, throughput, and error rates, automatically creating ServiceNow incidents when thresholds are breached. The incident includes contextual APM data such as recent deployments, database query performance, and infrastructure metrics to accelerate root cause analysis. ServiceNow assignment rules route incidents to appropriate application teams based on the affected service or application name extracted from New Relic metadata. This use case reduces mean time to detection (MTTD) and ensures performance issues are tracked through formal ITSM processes with proper escalation and communication workflows.

Infrastructure monitoring incident automation

New Relic Infrastructure monitoring detects server health issues, capacity problems, or service outages and automatically generates ServiceNow incidents with detailed system context. The integration enriches incidents with server specifications, resource utilization trends, and affected application dependencies to provide complete situational awareness. Incidents are automatically prioritized based on the criticality of affected infrastructure components and their business impact as defined in ServiceNow's CMDB. Resolution workflows in ServiceNow trigger infrastructure remediation runbooks and update New Relic with progress notes to maintain visibility across both monitoring and ticketing platforms.

Browser monitoring user experience incidents

New Relic Browser monitoring tracks real user experience metrics and creates ServiceNow incidents when page load times, JavaScript errors, or AJAX performance degrade beyond acceptable thresholds. The integration automatically populates incident records with user session data, geographic distribution of affected users, and browser compatibility information to support targeted troubleshooting efforts. ServiceNow workflows can trigger automated communication to affected user groups and coordinate with development teams for rapid issue resolution. Incident closure in ServiceNow automatically updates New Relic with resolution details and triggers post-incident analysis workflows to prevent similar user experience issues.

Synthetic monitoring proactive alerting

New Relic Synthetics continuously monitors critical business transactions and user workflows, creating ServiceNow incidents when synthetic tests fail or performance degrades. These proactive incidents include detailed test execution logs, screenshot evidence, and performance waterfall data to accelerate problem diagnosis before real users are impacted. ServiceNow major incident management processes are automatically triggered for critical synthetic failures, ensuring appropriate stakeholder notification and escalation procedures. The bidirectional sync ensures that ServiceNow resolution activities and communication updates are reflected in New Relic's incident timeline for complete audit trail maintenance.

Custom alert correlation and incident deduplication

Multiple New Relic alerts from related application components or infrastructure layers are intelligently correlated within ServiceNow to prevent incident flooding and focus response efforts on root cause analysis. The integration uses custom correlation logic based on application relationships defined in ServiceNow's CMDB to group related alerts into single parent incidents with child tasks for individual components. ServiceNow's event management capabilities process New Relic webhook notifications through correlation rules and noise reduction algorithms before creating incidents. This approach reduces alert fatigue while ensuring comprehensive visibility into complex, multi-tier application issues that span multiple monitoring domains within New Relic.

Troubleshooting

Webhook notifications from New Relic return 401 Unauthorized errors

Check that the ServiceNow user account used in New Relic's webhook configuration has sufficient privileges to access the Scripted REST API endpoint. Navigate to System Web Services > REST API Explorer to test endpoint accessibility with the integration user credentials. Verify that the endpoint ACL rules allow the integration user to POST to the webhook handler, and check System Logs > REST for detailed authentication error messages. If using basic authentication, ensure the password hasn't expired and that the user account is not locked due to failed login attempts.

New Relic webhook payload received but no incident record created in ServiceNow

Review the Scripted REST API execution logs in System Logs > Application Logs to identify JSON parsing errors or field validation failures during incident creation. Check that required fields in the incident table have appropriate default values or are being populated by the webhook script. Examine the New Relic webhook payload structure in the script debugger to ensure field mappings align with actual data format sent by New Relic. Verify that any choice list values (like priority or urgency) match valid options configured in ServiceNow's incident table dictionary.

Flow Designer enrichment workflow fails with REST API timeout errors

Check the New Relic API key permissions and rate limiting by testing direct API calls using the REST Message test functionality in ServiceNow. Navigate to System Web Services > Outbound > REST Message Log to examine detailed error responses and HTTP status codes from New Relic's API. Implement exponential backoff retry logic in the Flow Designer workflow to handle temporary API unavailability or rate limit exceeded responses. Consider reducing the frequency of enrichment calls or implementing caching mechanisms to store frequently accessed performance data and avoid unnecessary API requests.

Bidirectional sync updates New Relic but creates duplicate status changes

Implement condition checks in the Flow Designer workflow to prevent recursive updates by tracking the last sync timestamp in a custom incident field. Add workflow conditions to only process incidents where the state change originated from ServiceNow user actions rather than automated system updates. Review the New Relic incident API response handling to ensure proper acknowledgment prevents duplicate webhook delivery. Create a sync status tracking mechanism using incident work notes or custom fields to maintain state consistency between both systems and prevent infinite update loops.

Custom New Relic incident fields not populating despite successful webhook processing

Verify that custom fields added to the incident table have appropriate data types and field lengths to accommodate New Relic payload data. Check that the webhook processing script has proper error handling for undefined or null values from New Relic's JSON payload. Review field-level ACL configurations to ensure the integration user has write access to custom fields created for New Relic data storage. Test field population using the ServiceNow script debugger or background script execution to isolate field assignment issues from webhook processing problems.

Performance degradation in ServiceNow after enabling New Relic integration

Monitor the Flow Designer execution statistics and REST Message performance metrics to identify bottlenecks in workflow processing or API calls. Implement selective triggering conditions in Flow Designer to process only critical incidents rather than all New Relic-originated tickets. Review database performance impacts by analyzing slow query logs and considering indexing strategies for custom New Relic correlation fields. Optimize webhook processing by implementing asynchronous processing patterns using Business Rules with 'async' flag or scheduled jobs for non-critical data enrichment activities to prevent blocking incident creation workflows.

Pro Tips

  • Implement intelligent alert correlation by leveraging ServiceNow's CMDB relationships to group related New Relic alerts into single incidents, preventing alert fatigue while maintaining comprehensive visibility. Create custom correlation rules that examine application dependencies and infrastructure relationships to automatically link related performance issues across different New Relic monitoring domains like APM, Infrastructure, and Browser monitoring.
  • Design robust error handling and retry mechanisms in your Flow Designer workflows using exponential backoff patterns and circuit breaker logic to handle New Relic API rate limits gracefully. Store failed API calls in a retry queue table and implement scheduled jobs to reprocess failed enrichment requests during off-peak hours, ensuring no performance data is permanently lost due to temporary connectivity issues.
  • Optimize webhook processing performance by implementing payload validation and early filtering to reject malformed or duplicate notifications before expensive database operations. Use ServiceNow's Event Management capabilities to pre-process New Relic webhooks through correlation engines and noise reduction algorithms, significantly reducing the volume of incidents created while improving signal-to-noise ratio for operations teams.
  • Enhance incident response effectiveness by creating dynamic ServiceNow knowledge articles populated with New Relic runbook data and historical resolution patterns. Implement machine learning-assisted assignment rules that analyze New Relic alert characteristics, application context, and historical assignment patterns to route incidents to the most qualified resolver groups automatically.
  • Establish comprehensive monitoring and alerting for the integration itself by creating ServiceNow events when webhook processing fails, API quotas are approaching limits, or sync operations encounter errors. Build operational dashboards that track integration health metrics like webhook success rates, average enrichment processing times, and bidirectional sync accuracy to proactively identify and resolve integration issues.
  • Implement data retention and archival strategies for New Relic performance data stored in ServiceNow custom fields to prevent database bloat while maintaining historical analysis capabilities. Create automated cleanup jobs that archive detailed APM data to external storage systems after incident resolution while preserving key performance indicators and resolution patterns for future correlation and trending analysis.

Known Limitations

  • New Relic enforces API rate limits of 1000 requests per minute per account, which can impact real-time data enrichment for high-volume incident environments requiring careful throttling and prioritization strategies. The GraphQL API has separate rate limits that may further constrain advanced querying capabilities for detailed performance analytics integration scenarios.
  • ServiceNow's Integration Hub Professional license is required for advanced Flow Designer capabilities and complex webhook processing workflows, limiting integration sophistication for organizations with basic ServiceNow licensing tiers. Custom Scripted REST API endpoints require elevated development privileges and may not be available in strictly governed ServiceNow environments with restricted customization policies.
  • New Relic webhook notifications have a maximum payload size limitation and may not include all available context data for complex applications with extensive metadata, requiring additional API calls for complete incident enrichment. Webhook delivery guarantees are limited to a 72-hour retry window, potentially causing data loss during extended ServiceNow maintenance periods or network connectivity issues.
  • Bidirectional synchronization introduces potential race conditions and data consistency challenges when incidents are simultaneously updated in both systems, requiring careful state management and conflict resolution strategies. Real-time sync capabilities are limited by both platforms' API processing times and may introduce noticeable delays during peak usage periods.
  • New Relic's incident correlation and deduplication features may conflict with ServiceNow's event management correlation rules, potentially creating duplicate or contradictory incident states that require manual intervention. The integration cannot automatically map all New Relic alert severity levels to ServiceNow priority/urgency matrices without custom business logic and organizational alignment on escalation procedures.

Frequently Asked Questions

Can this integration handle New Relic alerts from multiple accounts within a single ServiceNow instance?

Yes, you can configure multiple REST Message records and webhook endpoints to handle different New Relic accounts by creating separate Scripted REST API resources with account-specific processing logic. Each New Relic account requires its own API credential stored in ServiceNow and corresponding webhook configuration with unique endpoint paths like '/incident/account1' and '/incident/account2'. The webhook processing script can identify the source account and apply different incident routing, assignment, or enrichment rules based on account context. Consider implementing a configuration table to maintain account-specific settings and field mappings for scalable multi-account management.

How can I prevent duplicate incidents when the same New Relic alert triggers multiple webhook notifications?

Implement deduplication logic in your Scripted REST API webhook handler by checking for existing incidents with matching u_alert_id values before creating new records. New Relic alert incidents have unique identifiers that can be used for correlation, and you can enhance this by implementing time-based deduplication windows using GlideDateTime calculations. Consider leveraging ServiceNow's Event Management module with correlation rules that can automatically deduplicate and correlate related New Relic events before incident creation. For complex scenarios, implement a staging table that buffers incoming webhooks for processing through scheduled jobs with built-in deduplication and correlation logic.

What New Relic data can be synchronized back from ServiceNow incident resolution activities?

ServiceNow can push incident resolution status, work notes, root cause analysis, and resolution timestamps back to New Relic through the Incidents API, maintaining comprehensive audit trails across both platforms. You can also synchronize assignment group information, escalation activities, and custom field data that provides operational context for New Relic users reviewing incident histories. The integration supports updating New Relic incident priority, status transitions, and even custom metadata fields defined in your New Relic account configuration. Advanced implementations can synchronize ServiceNow knowledge article references, related problem records, and change management associations to provide comprehensive incident lifecycle visibility within New Relic's interface.

Is it possible to trigger ServiceNow change management processes from New Relic deployment markers or events?

Yes, New Relic deployment markers can trigger ServiceNow change request creation through webhook notifications configured in New Relic's deployment tracking features. Configure separate webhook endpoints in ServiceNow to process deployment events and automatically create change requests with deployment details, application context, and performance impact analysis. The integration can correlate New Relic deployment markers with subsequent performance alerts to automatically associate incidents with recent changes, supporting comprehensive change impact assessment. Consider implementing approval workflows that update New Relic with change approval status and automatically create deployment tracking records that link ServiceNow change management with New Relic's application monitoring timeline.

How do I handle New Relic alert policy changes that might affect existing ServiceNow incident routing rules?

Implement a configuration management approach using ServiceNow tables to maintain mappings between New Relic alert policies and ServiceNow assignment rules, allowing dynamic updates without code changes. Create administrative interfaces for ITOM teams to manage alert-to-team mappings and automatically update Flow Designer conditions through ServiceNow's Flow API when policy changes occur. Consider implementing webhook notifications for New Relic configuration changes that can trigger ServiceNow workflows to validate and update routing rules automatically. Establish periodic synchronization jobs that compare New Relic alert policy configurations with ServiceNow routing rules and generate notifications or automatic updates when discrepancies are detected.

Can ServiceNow leverage New Relic's AI-powered anomaly detection for proactive incident management?

ServiceNow can consume New Relic's AI-driven alerts through webhook integrations, enabling proactive incident creation based on anomaly detection rather than static threshold breaches. Configure New Relic Applied Intelligence webhook notifications to trigger ServiceNow predictive analytics workflows that can correlate anomalies with historical incident patterns and CMDB relationships. The integration can populate ServiceNow incidents with AI-generated insights, correlation analysis, and suggested resolution paths derived from New Relic's machine learning algorithms. Advanced implementations can feed ServiceNow incident resolution data back into New Relic's AI models for improved future anomaly detection accuracy and reduced false positive rates in your specific operational environment.

What security considerations should I implement for New Relic webhook authentication in ServiceNow?

Implement webhook endpoint security using ServiceNow's built-in authentication mechanisms, IP address restrictions, and request signing validation to ensure only legitimate New Relic notifications are processed. Store New Relic API keys in ServiceNow's encrypted credential store and rotate them regularly using automated processes that update both ServiceNow configurations and New Relic webhook settings simultaneously. Configure webhook endpoints with HTTPS-only access, implement request rate limiting to prevent abuse, and use ServiceNow's audit logging to track all webhook processing activities for security monitoring. Consider implementing webhook payload signature verification using shared secrets to cryptographically validate that notifications originate from New Relic and haven't been tampered with during transmission.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue