The ServiceNow Nagios integration enables organizations to automatically forward Nagios host and service check alerts into ServiceNow Event Management, creating a centralized hub for IT operations monitoring and incident response. This integration is essential for enterprises running hybrid monitoring environments where Nagios monitors infrastructure while ServiceNow serves as the primary ITSM platform for incident management and workflow orchestration. The integration supports uni-directional data flow from Nagios to ServiceNow through REST API calls triggered by Nagios notification commands, with events automatically processed through Event Management rules to create incidents, change CI states, and trigger workflow automation. All integration components reside within ServiceNow's Event Management module and leverage REST Table APIs for inbound event processing.
Prerequisites
- •ServiceNow Quebec or later with Event Management plugin active
- •Nagios Core 4.x or Nagios XI with custom notification command capability
- •ServiceNow web_service role assigned to integration user account
- •evt_mgmt_integration role for event processing configuration
- •Network connectivity from Nagios server to ServiceNow instance on port 443
- •Basic authentication or OAuth 2.0 credentials configured for ServiceNow API access
- •Administrator access to Nagios configuration files and notification commands
Architecture Overview
The integration uses ServiceNow's native Event Management REST API (em_event table) without requiring specific Integration Hub spokes, processing inbound events through custom Nagios notification commands that make HTTP POST calls to ServiceNow. Authentication is established using Basic Authentication with ServiceNow credentials stored securely in Nagios configuration files, or preferably through OAuth 2.0 with client credentials managed in Connection & Credential Aliases if using a MID Server for enhanced security. Data flows uni-directionally from Nagios to ServiceNow when host or service state changes trigger notification commands that POST JSON payloads to the Event Management API endpoint. No MID Server is strictly required since Nagios initiates outbound connections to ServiceNow, but organizations may choose to route traffic through a MID Server for network security compliance and credential management. The ServiceNow Event Management engine processes inbound events at high volume with built-in deduplication and correlation, though organizations should monitor API rate limits which default to 1000 requests per hour per user for REST Table API calls.
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Implementation Steps
Create ServiceNow integration user and configure authentication credentials
Navigate to User Administration > Users and create a dedicated service account for Nagios integration with username like 'nagios.integration'. Assign the web_service role and evt_mgmt_integration role to enable API access and Event Management operations. Set a strong password and document the credentials securely as they will be configured in Nagios notification commands. For enhanced security in production environments, consider creating OAuth application credentials by navigating to System OAuth > Application Registry and creating a new client credentials flow application. Record the client ID and client secret for use in Nagios configuration files, ensuring the integration user has appropriate role assignments for OAuth token generation.
Configure Event Management parsing rules and transform maps for Nagios events
Navigate to Event Management > Event Processing > Event Rules and create a new event rule specifically for Nagios events by setting the condition 'Source equals nagios'. Configure the transform map to populate incident fields appropriately, mapping Nagios severity levels to ServiceNow impact and urgency values using field mapping rules. Set up proper CI identification by mapping Nagios hostnames to ServiceNow CMDB CI records using the 'Node' field, ensuring accurate asset correlation. Create additional processing rules for service vs host events, as Nagios differentiates between these event types and they may require different incident categorization and assignment group routing in ServiceNow.
// Event Rule Script for Nagios event processing
(function processNagiosEvent(event) {
// Map Nagios states to ServiceNow severity
var severityMap = {
'CRITICAL': 1, 'DOWN': 1,
'WARNING': 3, 'UNKNOWN': 3,
'OK': 5, 'UP': 5
};
event.severity = severityMap[event.state] || 3;
// Set event type based on Nagios notification type
if (event.notification_type == 'HOST') {
event.event_class = 'Infrastructure';
event.resource = event.hostname;
} else {
event.event_class = 'Application';
event.resource = event.hostname + ':' + event.service_desc;
}
})(event);Install and configure Nagios notification command scripts for ServiceNow integration
On the Nagios server, create a custom notification command script (typically /usr/local/bin/servicenow_notify.sh) that formats Nagios macros into JSON payloads and posts them to ServiceNow Event Management API. The script should extract key Nagios variables like $HOSTNAME$, $SERVICEDESC$, $SERVICESTATE$, $HOSTSTATE$, and $NOTIFICATIONTYPE$ and map them to ServiceNow event fields including source, node, description, and severity. Ensure the script includes proper error handling and logging to /var/log/nagios/servicenow_integration.log for troubleshooting failed API calls. Configure execute permissions (chmod +x) on the script and test connectivity to your ServiceNow instance using curl commands before integrating with Nagios notification workflows.
#!/bin/bash
# ServiceNow Event Management notification script
SN_INSTANCE="https://yourinstance.service-now.com"
SN_USER="nagios.integration"
SN_PASS="your_password"
# Build JSON payload from Nagios macros
JSON_PAYLOAD=$(cat <<EOF
{
"source": "nagios",
"node": "$1",
"type": "$2",
"severity": "$3",
"description": "$4",
"state": "$5",
"time_of_event": "$(date -u +%Y-%m-%d %H:%M:%S)"
}
EOF
)
# POST to ServiceNow Event Management API
curl -X POST "$SN_INSTANCE/api/now/table/em_event" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-u "$SN_USER:$SN_PASS" \
-d "$JSON_PAYLOAD" \
>> /var/log/nagios/servicenow.log 2>&1Define Nagios notification commands in commands.cfg for ServiceNow integration
Edit your Nagios commands.cfg file (typically /usr/local/nagios/etc/objects/commands.cfg) and define new notification commands that call your ServiceNow integration script with appropriate Nagios macro parameters. Create separate commands for host notifications (notify-host-by-servicenow) and service notifications (notify-service-by-servicenow) since they require different macro sets and field mappings. The command definitions should pass essential Nagios macros like $HOSTNAME$, $HOSTSTATE$, $SERVICEDESC$, $SERVICESTATE$, and $LONGDATETIME$ as arguments to your notification script. Verify the command syntax using nagios -v /usr/local/nagios/etc/nagios.cfg before restarting Nagios to ensure configuration validity and prevent service disruption.
# Host notification command for ServiceNow
define command {
command_name notify-host-by-servicenow
command_line /usr/local/bin/servicenow_notify.sh "$HOSTNAME$" "HOST" "$HOSTSTATE$" "Host $HOSTSTATE$: $HOSTOUTPUT$" "$HOSTSTATE$"
}
# Service notification command for ServiceNow
define command {
command_name notify-service-by-servicenow
command_line /usr/local/bin/servicenow_notify.sh "$HOSTNAME$" "SERVICE" "$SERVICESTATE$" "$SERVICEDESC$ $SERVICESTATE$: $SERVICEOUTPUT$" "$SERVICESTATE$"
}Configure Nagios contacts and contact groups for ServiceNow notifications
Create a dedicated Nagios contact definition in your contacts.cfg file specifically for ServiceNow integration, setting the contact_name to something like 'servicenow-integration'. Configure the host_notification_commands and service_notification_commands to use your newly created ServiceNow notification commands (notify-host-by-servicenow and notify-service-by-servicenow). Set appropriate notification periods and options, typically enabling notifications for critical, warning, and recovery states (host_notification_options w,u,c,r and service_notification_options w,u,c,r). Create a contact group containing this ServiceNow contact and assign it to hosts and services that should generate ServiceNow events, allowing you to selectively control which Nagios monitoring objects integrate with ServiceNow Event Management.
# ServiceNow integration contact definition
define contact {
contact_name servicenow-integration
alias ServiceNow Event Management
host_notification_period 24x7
service_notification_period 24x7
host_notification_options d,u,r
service_notification_options w,u,c,r
host_notification_commands notify-host-by-servicenow
service_notification_commands notify-service-by-servicenow
email nagios@yourcompany.com
}
# Contact group for ServiceNow integration
define contactgroup {
contactgroup_name servicenow-admins
alias ServiceNow Integration Group
members servicenow-integration
}Configure ServiceNow Event Management correlation and incident creation rules
Navigate to Event Management > Event Processing > Event Rules and create correlation rules that group related Nagios events to prevent incident flooding during widespread outages. Configure parent-child relationships by mapping Nagios host dependencies to ServiceNow CI relationships, ensuring dependent service failures don't create separate incidents when the parent host is down. Set up automatic incident creation rules by navigating to Event Management > Event Processing > Connectors and configuring the 'Create Incident' connector with appropriate field mappings from events to incidents. Define escalation timers and assignment group routing based on Nagios service categories or host groups, ensuring critical infrastructure alerts reach the appropriate response teams within your organization's SLA requirements.
// Event correlation script for related Nagios events
(function correlateNagiosEvents(event) {
var gr = new GlideRecord('em_event');
gr.addQuery('source', 'nagios');
gr.addQuery('node', event.node);
gr.addQuery('state', 'New');
gr.addQuery('sys_created_on', '>', gs.daysAgoStart(0));
gr.query();
if (gr.getRowCount() > 1) {
// Correlate with existing events from same node
event.correlation_id = event.node + '_' + gs.nowDateTime().getDisplayValue().substring(0,10);
event.correlation_display = 'Multiple issues on ' + event.node;
}
})(event);Implement bidirectional state synchronization between Nagios and ServiceNow
Create a scheduled script execution or business rule that monitors incident state changes in ServiceNow and optionally sends acknowledgments back to Nagios when incidents are assigned or resolved. Navigate to System Definition > Business Rules and create an 'async' business rule on the Incident table that triggers on state changes to 'In Progress' or 'Resolved'. The business rule should identify incidents created from Nagios events using the correlation ID or event reference, then make outbound REST calls to Nagios XI's API or write acknowledgment files to Nagios Core's external command pipe. Configure the integration to suppress further notifications from Nagios when ServiceNow incidents are actively being worked, reducing noise and preventing notification storms during incident response activities.
// Business rule to acknowledge Nagios alerts when ServiceNow incident is assigned
(function executeRule(current, previous) {
if (current.state == 2 && previous.state == 1) { // Assigned state
var event = new GlideRecord('em_event');
if (event.get(current.correlation_id)) {
if (event.source == 'nagios') {
var rm = new sn_ws.RESTMessageV2();
rm.setEndpoint('https://nagios-server/nagiosxi/api/v1/objects/acknowledgement');
rm.setHttpMethod('POST');
rm.setBasicAuth('nagiosapi', 'password');
var payload = {
'host_name': event.node.toString(),
'service_description': event.resource.toString(),
'comment': 'Acknowledged via ServiceNow incident ' + current.number
};
rm.setRequestBody(JSON.stringify(payload));
rm.execute();
}
}
}
})(current, previous);Test the integration end-to-end and configure monitoring dashboards
Perform comprehensive testing by triggering test alerts in Nagios using the nagios command-line utility or by temporarily setting aggressive check thresholds on non-critical services to generate state changes. Monitor the ServiceNow Event Management dashboard to verify events are being created with correct field mappings, severity levels, and correlation logic. Verify that incidents are automatically created according to your configured rules and assigned to appropriate groups based on the event classification. Create custom ServiceNow dashboards and reports in Performance Analytics or standard reporting to track integration health metrics including event volume, incident creation rates, and API call success rates. Configure alerting within ServiceNow to notify administrators if the Nagios integration stops sending events, indicating potential connectivity or configuration issues requiring immediate attention.
// Integration health check script for scheduled execution
(function checkNagiosIntegrationHealth() {
var eventCount = new GlideAggregate('em_event');
eventCount.addQuery('source', 'nagios');
eventCount.addQuery('sys_created_on', '>', gs.hoursAgoStart(1));
eventCount.query();
var recentEvents = eventCount.getRowCount();
if (recentEvents == 0) {
// No events received in past hour - alert administrators
var incident = new GlideRecord('incident');
incident.initialize();
incident.short_description = 'Nagios integration health check failed';
incident.description = 'No Nagios events received in the past hour. Check connectivity and notification commands.';
incident.category = 'Software';
incident.subcategory = 'Monitoring';
incident.priority = 2;
incident.assignment_group = 'IT Operations';
incident.insert();
}
})();Common Use Cases
Critical infrastructure monitoring and automated incident creation
Nagios monitors critical servers, network devices, and database systems, automatically creating P1 incidents in ServiceNow when hosts go down or critical services fail. The integration maps Nagios CRITICAL and DOWN states to high-impact incidents with appropriate assignment group routing based on CI categories. ServiceNow Event Management correlates related infrastructure failures to prevent incident flooding during widespread outages. This ensures rapid response to business-critical system failures while maintaining organized incident management workflows and SLA compliance tracking.
Application service monitoring with automated escalation workflows
Web applications and business services monitored by Nagios generate events in ServiceNow Event Management when response times exceed thresholds or availability checks fail. The integration creates incidents with contextual information including service descriptions, performance metrics, and affected business processes mapped from Nagios service definitions. ServiceNow workflow automation triggers escalation procedures, stakeholder notifications, and emergency response protocols based on service criticality levels. This enables proactive application performance management with consistent incident response processes across all monitored applications.
Network device monitoring with CI relationship awareness
Nagios monitors network switches, routers, and wireless access points, sending alerts to ServiceNow with automatic CI correlation based on hostname and IP address matching. The integration leverages ServiceNow CMDB relationships to suppress dependent device alerts when upstream network equipment fails, reducing noise during network outages. Events include network-specific context like interface utilization, packet loss metrics, and SNMP status codes from Nagios check results. This provides comprehensive network visibility while maintaining clean incident management during cascade failures and planned maintenance windows.
Security monitoring integration with threat response workflows
Nagios security plugins monitoring for malware, unauthorized access attempts, and compliance violations send high-priority alerts to ServiceNow Event Management for centralized security incident response. The integration automatically assigns security events to specialized security operations teams and triggers predefined response workflows including evidence preservation and stakeholder notification. Events include detailed security context from Nagios including threat signatures, affected systems, and initial remediation recommendations. This enables coordinated security incident response with proper documentation, compliance reporting, and forensic chain of custody through ServiceNow case management.
Capacity planning and performance trend analysis integration
Nagios performance data monitoring for disk space, memory utilization, and CPU load generates ServiceNow events when warning thresholds are exceeded, enabling proactive capacity management. The integration creates low-priority incidents for trending analysis and capacity planning tasks rather than immediate emergency response. ServiceNow Performance Analytics consumes event data to build long-term performance trending reports and capacity forecasting models. This supports strategic IT planning decisions while maintaining operational awareness of resource utilization patterns and growth trends across the monitored infrastructure environment.
Troubleshooting
Nagios notification commands execute but no events appear in ServiceNow Event Management
Check the Nagios notification script execution log (/var/log/nagios/servicenow.log) for HTTP response codes and error messages from the ServiceNow API calls. Verify the ServiceNow instance URL, authentication credentials, and network connectivity by testing the API endpoint manually using curl with identical parameters. Confirm the integration user has both web_service and evt_mgmt_integration roles assigned, and validate the JSON payload format matches ServiceNow Event Management API requirements. Enable debug logging in the notification script to capture full request/response details for detailed troubleshooting of API communication failures.
Events are created in ServiceNow but incidents are not automatically generated from Nagios alerts
Navigate to Event Management > Event Processing > Processing Log to review event processing status and identify rule execution failures or transform map errors. Verify that Event Rules are properly configured with correct source matching criteria ('source equals nagios') and that the incident creation connector is active and properly mapped. Check the Event Rule conditions and ensure they match the actual event field values being sent from Nagios, particularly the severity and state field mappings. Test the incident creation rules manually using the Event Management interface to isolate configuration issues from payload format problems.
ServiceNow receives duplicate events for the same Nagios alert causing multiple incidents
Review Nagios notification settings to ensure notification intervals and escalation configurations aren't causing repeated notifications for the same state changes. Configure ServiceNow Event Management correlation rules to group related events by node and service description within specified time windows to prevent duplicate incident creation. Verify the Nagios notification_options settings only include state transitions (w,u,c,r) rather than periodic notifications (f,n) which can flood ServiceNow with redundant events. Implement proper event deduplication logic in ServiceNow using correlation_id fields based on unique combinations of hostname, service, and state information.
Authentication failures with 401 Unauthorized errors in Nagios ServiceNow API calls
Verify the ServiceNow integration user credentials are correct and the account hasn't been locked due to failed login attempts by checking User Administration > Users. Confirm the user has active status and required roles (web_service, evt_mgmt_integration) by reviewing role assignments in the user record. Test authentication manually using a REST client or curl command with identical credentials to isolate script configuration issues from account problems. If using OAuth 2.0, verify the client credentials flow is properly configured and tokens are being generated successfully by checking System OAuth > Token Management for recent token generation activity.
Events are processed but CI correlation fails resulting in incidents without proper asset relationships
Verify that Nagios hostnames exactly match ServiceNow CI names or IP addresses in the CMDB by comparing event.node values with actual CI records in the cmdb_ci table. Configure hostname normalization in the Event Rule processing scripts to handle FQDN versus short hostname mismatches between Nagios and ServiceNow CMDB entries. Review CI identification rules in Event Management and ensure proper field mappings between Nagios host identifiers and ServiceNow CI correlation fields. Use ServiceNow Discovery or manual CI updates to ensure monitored systems are properly represented in the CMDB with consistent naming conventions matching Nagios host definitions.
High latency in event processing causing delayed incident creation from Nagios alerts
Monitor ServiceNow Event Management processing queue depth and performance metrics in Event Management > Administration > Processing Stats to identify bottlenecks in event rule execution. Review complex event correlation rules and transform map scripts that may be causing processing delays, optimizing database queries and reducing computational complexity. Check for API rate limiting issues by monitoring REST API usage in System Logs > REST API Activity and consider implementing request throttling in Nagios notification scripts if approaching ServiceNow API limits. Verify adequate ServiceNow instance resources and consider upgrading instance sizing if event processing consistently falls behind during peak notification periods.
Pro Tips
- →Implement event aging and cleanup policies in ServiceNow Event Management to automatically close resolved events after 30 days and archive historical data to prevent database bloat from high-volume Nagios monitoring environments. Configure custom event fields to capture Nagios-specific metadata like check command names and performance data for enhanced troubleshooting capabilities during incident response.
- →Use ServiceNow Business Rules with conditional logic to automatically suppress events during planned maintenance windows by cross-referencing Change Management schedules, preventing false alerts when systems are intentionally offline. Create custom notification schemes that escalate unacknowledged critical events from Nagios through multiple ServiceNow communication channels including email, SMS, and collaboration platform integrations.
- →Leverage ServiceNow Performance Analytics to build executive dashboards showing infrastructure health trends, mean time to detection, and incident response metrics derived from Nagios event data. Implement custom correlation rules that consider ServiceNow CMDB relationships to automatically identify blast radius and affected services when critical infrastructure components monitored by Nagios experience failures.
- →Configure Nagios notification command rate limiting and batching to prevent API flooding during mass outage scenarios, using temporary files to queue events and process them in controlled intervals. Set up bidirectional integration health monitoring where ServiceNow periodically polls Nagios API endpoints to verify integration connectivity and automatically creates alerts when the monitoring system itself becomes unreachable.
- →Implement advanced event enrichment using ServiceNow's external API capabilities to augment Nagios events with additional context from monitoring tools, asset databases, and business service catalogs. Create intelligent event filtering rules that suppress low-priority alerts during business hours but escalate after-hours events to ensure appropriate response timing based on business impact analysis.
- →Use ServiceNow's Connection & Credential Aliases with MID Server deployment for enhanced security, storing sensitive Nagios API credentials in encrypted vaults rather than plain text configuration files. Implement event source validation and integrity checking to ensure Nagios events haven't been tampered with during transmission, adding cryptographic signatures to notification payloads where security requirements demand non-repudiation.
Known Limitations
- —ServiceNow REST API rate limits default to 1000 requests per hour per user, which may be insufficient for large Nagios environments monitoring thousands of hosts and services during outage scenarios. Organizations must implement request throttling, credential rotation, or upgrade to higher API limit tiers to handle peak notification volumes without losing critical alerts.
- —The integration relies on network connectivity between Nagios servers and ServiceNow instances, creating potential single points of failure during network outages that could prevent critical infrastructure alerts from reaching incident management teams. Nagios notification scripts lack built-in retry mechanisms and persistent queuing, potentially losing events during temporary connectivity issues.
- —Nagios hostname and service description formats may not directly correlate with ServiceNow CMDB CI naming conventions, requiring extensive configuration management and ongoing synchronization to maintain accurate asset relationships. Complex multi-tier applications monitored by Nagios may not map cleanly to ServiceNow business service models, limiting automated impact analysis capabilities.
Frequently Asked Questions
Can the Nagios integration automatically resolve ServiceNow incidents when Nagios alerts return to OK status?
Yes, configure Nagios recovery notifications to send OK state events to ServiceNow Event Management, then create Event Rules that automatically resolve corresponding incidents based on correlation IDs. Set up the recovery notification commands to include state transition information and implement ServiceNow business rules that update incident states when recovery events are processed. This requires careful correlation logic to match recovery events with original problem events, typically using combinations of hostname, service description, and time window matching. Consider implementing approval workflows for automatic closure of high-priority incidents to ensure proper verification of service restoration.
How do I prevent ServiceNow incident flooding when Nagios detects widespread network outages affecting hundreds of devices?
Implement ServiceNow Event Management correlation rules that group related events by network segments, parent-child CI relationships, or geographic locations to create single master incidents for cascade failures. Configure event processing delays and batching windows that allow multiple related events to be collected before incident creation, reducing noise during rapid-fire notification scenarios. Use Nagios parent-host dependencies and network topology awareness to suppress dependent device notifications at the Nagios level, preventing unnecessary events from reaching ServiceNow during upstream network failures. Set up ServiceNow business rules that automatically identify and merge duplicate incidents created within specified time windows for the same business service or infrastructure component.
What ServiceNow roles and permissions are required for users to configure and maintain the Nagios integration?
Integration configuration requires evt_mgmt_admin role for Event Management rule creation and evt_mgmt_integration role for event processing configuration access. Users need rest_api_explorer role to test and troubleshoot REST API endpoints, and connection_admin role if using Connection & Credential Aliases for secure authentication management. Administrative users should have system_administrator or delegated_developer roles to create custom business rules, transform maps, and workflow modifications. For ongoing maintenance and troubleshooting, assign evt_mgmt_user role to operations staff who need visibility into event processing logs and correlation rule performance without full administrative access.
Can I customize which Nagios alert fields are mapped to specific ServiceNow incident and event fields?
Yes, customize field mappings through Event Management transform maps and Event Rules processing scripts that parse incoming JSON payloads and populate ServiceNow fields based on Nagios macro values. Modify the Nagios notification command scripts to include additional macro variables like $HOSTGROUPNAME$, $SERVICEGROUPS$, or custom variables from Nagios host and service definitions. Create conditional mapping logic in ServiceNow Event Rules that route different types of Nagios alerts to different incident categories, assignment groups, or priority levels based on service classifications or host attributes. Use ServiceNow's script-based field mapping capabilities to implement complex data transformations, lookups, and business logic during event processing.
How can I monitor the health and performance of the Nagios ServiceNow integration itself?
Create ServiceNow scheduled scripts that monitor event ingestion rates, API call success rates, and processing latency metrics by analyzing Event Management tables and REST API logs. Implement Nagios checks that monitor ServiceNow API endpoint availability and response times, creating circular monitoring that alerts when the integration pathway itself fails. Set up ServiceNow Performance Analytics widgets to track integration KPIs including events processed per hour, incident creation rates, and correlation rule effectiveness over time. Configure automated health checks that generate test events from Nagios and verify end-to-end processing through ServiceNow incident creation, alerting operations teams when integration workflows break or performance degrades below acceptable thresholds.
Does the integration support ServiceNow's multi-instance environments or managed service provider deployments?
The integration supports multi-instance deployments by configuring separate Nagios notification commands and authentication credentials for each ServiceNow instance, allowing different business units or customers to receive events in isolated ServiceNow environments. Configure Nagios host and service templates with custom variables that specify target ServiceNow instances, enabling dynamic routing of events based on organizational boundaries or service ownership. Managed service providers can implement tenant isolation by using different integration user accounts, event correlation rules, and assignment group routing for each customer instance. Consider implementing centralized credential management and monitoring dashboards that provide MSP administrators with visibility across all customer integrations while maintaining proper access controls and data separation.
What happens to in-flight events and incidents during ServiceNow instance upgrades or maintenance windows?
During ServiceNow maintenance windows, Nagios notification scripts will receive HTTP errors and should implement retry logic with exponential backoff to queue failed API calls until the instance becomes available again. Configure Nagios to log failed notification attempts and consider implementing local event storage mechanisms that can replay missed alerts after ServiceNow maintenance completes. Existing incidents and events in ServiceNow remain unchanged during upgrades, but active event processing workflows may be temporarily interrupted until system services restart. Plan integration testing as part of ServiceNow upgrade procedures to verify Event Management rules, API endpoints, and custom business rules continue functioning correctly after platform updates, and maintain rollback procedures for integration-specific customizations.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue