The ServiceNow Cisco ThousandEyes integration enables automated incident creation from network and application performance alerts, providing IT operations teams with immediate visibility into connectivity issues. This integration is primarily used by network operations centers, site reliability engineers, and service desk teams who need to correlate network performance degradation with business impact and automate response workflows. The integration supports unidirectional data flow from ThousandEyes to ServiceNow, triggered by webhook alerts when network tests exceed defined thresholds. ServiceNow receives alert payloads containing network path data, traceroute information, and performance metrics, automatically enriching incident records with contextual network intelligence through the Event Management module and Integration Hub platform.
Prerequisites
- •ServiceNow Quebec or later with Integration Hub Professional license
- •Cisco ThousandEyes Standard or Enterprise license with API access enabled
- •Event Management plugin (com.snc.em) activated in ServiceNow instance
- •sys_admin or equivalent role with access to Connection & Credential Aliases
- •ThousandEyes organization admin or account admin role for webhook configuration
- •Outbound internet connectivity from ServiceNow instance (no MID Server required for webhook reception)
- •SSL certificate validation capability for ThousandEyes API endpoints
Architecture Overview
The integration uses ServiceNow's native Scripted REST API capabilities to receive webhook payloads from ThousandEyes, eliminating the need for a dedicated Integration Hub spoke. Authentication is established using ThousandEyes API credentials stored in Connection & Credential Aliases, enabling secure outbound calls to enrich incident data with additional network metrics and historical performance data. Data flows unidirectionally from ThousandEyes to ServiceNow, triggered by alert conditions configured in ThousandEyes test configurations, with webhook payloads processed by custom Scripted REST API endpoints. No MID Server is required since ServiceNow acts as the webhook receiver, though outbound API calls to ThousandEyes for data enrichment are made directly from the ServiceNow instance. ThousandEyes enforces rate limits of 240 requests per minute per organization, requiring careful consideration when implementing bulk data retrieval or real-time enrichment workflows.
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 ThousandEyes OAuth Bearer Token and ServiceNow Credential
Log into your ThousandEyes dashboard and navigate to Account Settings > Users and Roles > User API Tokens to generate a new OAuth Bearer Token with appropriate read permissions for tests and alerts. Copy the generated token and navigate to ServiceNow at Connections & Credentials > Credentials, then click New to create a Basic Auth credential record. Set the Name field to 'ThousandEyes_API_Token', leave Username blank, and paste the OAuth token into the Password field. Verify the credential is active and note the sys_id for use in REST message configurations.
Configure Connection Alias for ThousandEyes API
Navigate to Connections & Credentials > Connection Aliases and create a new Connection Alias with Name 'ThousandEyes_API_Connection' and Connection URL 'https://api.thousandeyes.com/v6/'. Set the Credential reference to the ThousandEyes_API_Token credential created in step 1 and configure Connection timeout to 30 seconds. Enable 'Use MID Server' only if your instance requires it for outbound HTTPS connections, otherwise leave it disabled for direct cloud-to-cloud communication. Test the connection alias to ensure successful authentication to the ThousandEyes API endpoints.
Create Scripted REST API Resource for ThousandEyes Webhooks
Navigate to System Web Services > Scripted Web Services > Scripted REST APIs and create a new API with Name 'ThousandEyes Integration' and API ID 'thousandeyes_webhook'. Create a new Resource with Name 'Alert Handler', Relative path '/alert', and HTTP method 'POST'. Set Security to 'Require authentication' and configure appropriate ACL restrictions to limit access to the ThousandEyes webhook source IPs. The resource will process incoming alert payloads and transform them into ServiceNow incident or event records based on alert severity and test type.
Implement Webhook Processing Script for Alert Transformation
In the Scripted REST Resource created in step 3, implement the POST processing script to parse incoming ThousandEyes alert payloads and create corresponding incident records. The script should extract key alert properties including test name, alert type, affected locations, and performance metrics to populate incident fields appropriately. Implement error handling for malformed payloads and include logging statements for troubleshooting webhook delivery issues. Configure alert severity mapping to translate ThousandEyes alert levels into ServiceNow impact and urgency values.
(function process(request, response) {
try {
var requestBody = request.body.data;
var alert = JSON.parse(requestBody);
var inc = new GlideRecord('incident');
inc.initialize();
inc.short_description = 'ThousandEyes Alert: ' + alert.testName + ' - ' + alert.alertType;
inc.description = 'Alert Details: ' + alert.violationDescription + '\nAffected Agents: ' + alert.agents.join(', ');
inc.impact = alert.severity === 'critical' ? '1' : alert.severity === 'major' ? '2' : '3';
inc.urgency = '2';
inc.category = 'Network';
inc.u_thousandeyes_alert_id = alert.alertId;
inc.u_thousandeyes_test_id = alert.testId;
inc.insert();
response.setStatus(200);
response.setBody({'status': 'success', 'incident': inc.getDisplayValue()});
} catch (e) {
gs.error('ThousandEyes webhook processing error: ' + e.message);
response.setStatus(400);
response.setBody({'error': e.message});
}
})(request, response);Create Business Rule for Incident Enrichment with Network Data
Navigate to System Definition > Business Rules and create an 'after insert' business rule on the Incident table to enrich new ThousandEyes incidents with additional network path and performance data. Configure the condition to trigger only when the u_thousandeyes_alert_id field is populated, indicating the incident originated from a ThousandEyes webhook. The business rule should call the ThousandEyes API to retrieve detailed test results, network path visualization data, and historical performance metrics. Implement the enrichment as an asynchronous process to avoid blocking the initial incident creation and prevent timeout issues.
(function executeRule(current, previous) {
if (current.u_thousandeyes_alert_id && current.u_thousandeyes_test_id) {
var sm = new sn_ws.RESTMessageV2();
sm.setEndpoint('https://api.thousandeyes.com/v6/net/path-vis/' + current.u_thousandeyes_test_id);
sm.setHttpMethod('GET');
sm.setRequestHeader('Authorization', 'Bearer ' + gs.getProperty('thousandeyes.api.token'));
sm.setRequestHeader('Accept', 'application/json');
var response = sm.execute();
if (response.getStatusCode() == 200) {
var pathData = JSON.parse(response.getBody());
current.work_notes = 'Network Path Analysis: ' + pathData.net.pathVis.length + ' hops detected\n';
current.work_notes += 'End-to-end Loss: ' + pathData.net.loss + '%\n';
current.work_notes += 'Average Latency: ' + pathData.net.avgLatency + 'ms';
current.update();
}
}
})(current, previous);Configure Transform Map for Event-to-Incident Conversion
Navigate to Event Management > Transform Maps and create a new transform map to convert ThousandEyes events into incidents when alert conditions persist beyond defined thresholds. Set the source table to 'Event [em_event]' and target table to 'Incident [incident]' with conditions matching events where source='ThousandEyes'. Map essential fields including event description to incident short_description, additional_info to description, and severity to impact/urgency combinations. Configure field mapping for custom ThousandEyes-specific fields like test ID, agent locations, and metric thresholds to preserve network monitoring context in the incident record.
Set Up ThousandEyes Alert Rules and Webhook Configuration
In the ThousandEyes dashboard, navigate to Alerts > Alert Rules and create or modify existing alert rules to include webhook notifications pointing to your ServiceNow Scripted REST API endpoint. Configure the webhook URL as 'https://[your-instance].service-now.com/api/sn_ws/thousandeyes_webhook/alert' and set the HTTP method to POST with JSON payload format. Define appropriate alert conditions based on network performance thresholds, test types, and affected locations that warrant ServiceNow incident creation. Test the webhook delivery using ThousandEyes' webhook test functionality to verify successful payload delivery and incident creation.
Implement Scheduled Job for Historical Data Synchronization
Navigate to System Definition > Scheduled Jobs and create a daily scheduled script execution to synchronize historical ThousandEyes test data and maintain incident correlation accuracy. The scheduled job should query active incidents with ThousandEyes alert IDs and update them with the latest test status, performance metrics, and resolution timestamps from the ThousandEyes API. Implement appropriate error handling and logging to track synchronization failures and API rate limit violations. Configure the job to run during off-peak hours to minimize impact on system performance and respect ThousandEyes API rate limits.
var gr = new GlideRecord('incident');
gr.addQuery('active', true);
gr.addQuery('u_thousandeyes_alert_id', '!=', '');
gr.query();
while (gr.next()) {
try {
var rm = new sn_ws.RESTMessageV2();
rm.setEndpoint('https://api.thousandeyes.com/v6/alerts/' + gr.u_thousandeyes_alert_id);
rm.setHttpMethod('GET');
rm.setRequestHeader('Authorization', 'Bearer ' + gs.getProperty('thousandeyes.api.token'));
var response = rm.execute();
if (response.getStatusCode() == 200) {
var alertData = JSON.parse(response.getBody());
if (alertData.alert && alertData.alert.active === 0) {
gr.state = 6; // Resolved
gr.resolution_code = 'Solved (Permanently)';
gr.close_notes = 'Alert cleared in ThousandEyes at ' + alertData.alert.dateEnd;
gr.update();
}
}
} catch (e) {
gs.error('Error synchronizing ThousandEyes alert ' + gr.u_thousandeyes_alert_id + ': ' + e.message);
}
}Common Use Cases
Automated Network Outage Incident Creation
When ThousandEyes detects network connectivity failures or packet loss exceeding defined thresholds across multiple monitoring agents, webhooks automatically create high-priority incidents in ServiceNow. The incidents include network path visualization data, affected locations, and historical performance baselines to accelerate troubleshooting. Network operations teams receive immediate notification through ServiceNow's incident management workflows, enabling faster mean time to resolution for critical network outages. This use case is particularly valuable for organizations with geographically distributed infrastructure requiring 24/7 network monitoring.
Application Performance Degradation Tracking
ThousandEyes HTTP server and page load tests trigger ServiceNow incident creation when application response times exceed acceptable thresholds or when specific transaction steps fail. Incidents automatically include waterfall charts, DNS resolution timing, and SSL handshake performance data to help application teams identify root causes. The integration correlates application performance issues with underlying network conditions, providing comprehensive visibility into the full application delivery chain. Service desk teams can proactively communicate with end users about performance issues before help desk calls increase.
BGP Routing Anomaly Detection and Incident Management
ThousandEyes BGP monitoring detects routing path changes, AS path modifications, or reachability issues that could impact application performance or connectivity. ServiceNow incidents created from BGP alerts include routing table snapshots, path change timelines, and affected prefixes to assist network engineers in assessing routing stability. The integration enables correlation between BGP routing events and user-reported connectivity issues, helping teams understand the business impact of routing changes. Network operations teams can track routing incidents alongside other infrastructure issues for comprehensive network health reporting.
DNS Resolution Failure Incident Automation
When ThousandEyes DNS server tests detect resolution failures, timeout issues, or authoritative server problems, automatic incident creation in ServiceNow includes DNS query details, recursive resolution paths, and server response analysis. Incidents are enriched with DNS performance metrics from multiple vantage points to help identify whether issues are localized or widespread. The integration enables DNS administrators to track resolution issues across different DNS providers and geographic regions through centralized incident management. Critical DNS failures trigger high-priority incidents with appropriate escalation workflows to ensure rapid response for infrastructure-critical services.
Voice and Video Quality Incident Management
ThousandEyes voice and video quality tests trigger ServiceNow incidents when call quality metrics like Mean Opinion Score (MOS), jitter, or packet loss exceed acceptable thresholds for real-time communications. Incidents include voice quality analysis, network path quality assessments, and QoS marking effectiveness data to help unified communications teams troubleshoot quality issues. The integration correlates voice quality degradation with underlying network performance, enabling teams to address root causes rather than symptoms. Service desk teams receive enriched incident data to better assist users experiencing poor call quality or video conferencing issues.
Troubleshooting
Webhook payloads received but no incidents created in ServiceNow
Check the System Log for JavaScript errors in the Scripted REST API resource processing script and verify that required custom fields like u_thousandeyes_alert_id exist on the incident table. Navigate to System Web Services > REST API Explorer to test the webhook endpoint manually with sample ThousandEyes payload data. Ensure the Scripted REST API has appropriate security settings and that the webhook source IP addresses are not blocked by instance security rules. Verify that the user context executing the webhook script has sufficient privileges to create incident records.
401 Unauthorized errors when enriching incidents with ThousandEyes API data
Verify the ThousandEyes OAuth Bearer Token stored in the ServiceNow credential is valid and has not expired by testing it directly against the ThousandEyes API using a REST client. Check that the Connection Alias is properly configured with the correct credential reference and that the API endpoint URL uses the correct ThousandEyes API version. Review the outbound HTTP request logs under System Logs > Outbound HTTP Requests to examine the exact authentication headers being sent. Regenerate the ThousandEyes API token if necessary and update the ServiceNow credential record.
Duplicate incidents created for the same ThousandEyes alert
Implement deduplication logic in the webhook processing script by checking for existing incident records with the same u_thousandeyes_alert_id before creating new incidents. Add a unique constraint or create a business rule to prevent duplicate incident creation based on ThousandEyes alert identifiers. Consider implementing an event-based approach using the Event Management module to consolidate multiple webhook calls for the same alert condition. Review ThousandEyes alert rule configuration to ensure webhooks are not configured with excessive retry attempts that could cause duplicate notifications.
ThousandEyes API rate limit exceeded errors during bulk data retrieval
Implement exponential backoff retry logic in API calls and respect the 240 requests per minute rate limit by adding appropriate delays between consecutive API requests. Use batch processing in scheduled jobs to retrieve multiple test results in fewer API calls and cache frequently accessed data to reduce API consumption. Monitor API usage through ThousandEyes account settings and implement request queuing mechanisms to distribute API calls over time. Consider upgrading to higher ThousandEyes license tiers if API limits consistently impact integration functionality.
Network path and traceroute data not appearing in ServiceNow incidents
Verify that the business rule triggering data enrichment is configured correctly with proper table and timing conditions, and check that it executes after the initial incident creation webhook. Review the ThousandEyes API response format for path visualization data and ensure the parsing logic correctly extracts network hop information and performance metrics. Check System Logs for any errors in the enrichment business rule execution and verify that the API calls are successful with proper authentication. Confirm that the custom fields for storing network path data exist on the incident table and have appropriate data types for JSON storage.
Webhook SSL certificate validation failures from ThousandEyes
Ensure your ServiceNow instance has a valid SSL certificate that ThousandEyes can successfully validate during webhook delivery attempts. Check the instance's certificate chain and verify that intermediate certificates are properly configured if using a custom domain. Review ServiceNow instance security settings to ensure that TLS versions and cipher suites are compatible with ThousandEyes webhook requirements. Test webhook delivery using the ThousandEyes webhook test functionality and examine any SSL-related error messages in the delivery logs.
Pro Tips
- →Implement custom incident classification logic based on ThousandEyes test types to automatically route network, application, and BGP alerts to appropriate assignment groups, improving response efficiency and reducing manual triage overhead.
- →Use ServiceNow's Event Management correlation rules to group related ThousandEyes alerts from multiple tests or locations into single incidents, preventing alert storms during widespread network outages while maintaining visibility into affected services.
- →Create custom dashboards combining ServiceNow incident metrics with embedded ThousandEyes network performance data using iframe widgets or REST API integration to provide unified network health visibility for operations teams.
- →Configure alert suppression logic during scheduled maintenance windows by checking ServiceNow's Change Management schedule before creating incidents from ThousandEyes webhooks, reducing noise during planned network activities.
- →Leverage ServiceNow's Flow Designer to create automated remediation workflows that can trigger network device configuration changes or failover procedures based on specific ThousandEyes alert patterns and severity levels.
- →Implement historical trend analysis by storing ThousandEyes performance metrics in ServiceNow's Performance Analytics warehouse, enabling long-term network health reporting and capacity planning insights alongside incident management data.
Known Limitations
- —ThousandEyes API enforces a rate limit of 240 requests per minute per organization, which may constrain real-time data enrichment capabilities during high-volume alert periods or when implementing comprehensive historical data synchronization. Consider implementing request queuing and caching mechanisms to work within these limits.
- —ServiceNow's Scripted REST API webhook processing occurs synchronously, potentially causing timeout issues when processing complex ThousandEyes payloads or performing multiple API enrichment calls during incident creation. Implement asynchronous processing patterns using business rules or scheduled jobs for complex data operations.
- —ThousandEyes webhook delivery retry mechanisms may not align perfectly with ServiceNow's availability during maintenance windows or system updates, potentially resulting in missed alerts during critical infrastructure events. Implement compensating controls through scheduled API polling for mission-critical monitoring scenarios.
- —The integration requires custom field creation on ServiceNow tables to store ThousandEyes-specific metadata, which may impact upgrade compatibility and require additional testing during ServiceNow platform updates. Document custom fields thoroughly and plan for migration testing.
- —Network path visualization and traceroute data from ThousandEyes may contain large JSON payloads that exceed ServiceNow field size limitations, requiring data truncation or alternative storage strategies for comprehensive network diagnostic information. Consider using attachment storage for large diagnostic datasets.
Frequently Asked Questions
Can the integration automatically resolve ServiceNow incidents when ThousandEyes alerts clear?
Yes, you can implement automatic incident resolution by configuring ThousandEyes webhook notifications for alert clearing events and processing these in your Scripted REST API to update incident states. Additionally, the scheduled job approach described in the implementation steps can periodically check alert status via API and automatically resolve incidents when alerts are no longer active. This requires storing the ThousandEyes alert ID in the incident record and implementing proper state management logic to handle alert lifecycle events.
How do I handle ThousandEyes alerts that affect multiple ServiceNow services or configuration items?
Implement correlation logic in your webhook processing script that queries the ServiceNow CMDB to identify affected CIs based on network paths, IP addresses, or application URLs from ThousandEyes alerts. You can create multiple incident tasks or related records linking the primary incident to affected services, or use Event Management correlation rules to group related alerts. Consider creating custom relationship tables to map ThousandEyes test configurations to ServiceNow business services for automated impact assessment and stakeholder notification.
What ServiceNow roles and permissions are required for users to access ThousandEyes integration features?
Users need incident_manager or itil_admin roles to view and modify incidents created by the integration, while integration administrators require admin or integration_admin roles to configure Connection Aliases and Scripted REST APIs. For viewing enriched network data, users need read access to custom ThousandEyes fields on incident and event tables. Consider creating a custom role specifically for network operations teams that includes access to ThousandEyes-related fields and workflows while maintaining appropriate security boundaries for sensitive network monitoring data.
Can I integrate ThousandEyes with ServiceNow's IT Operations Management (ITOM) modules?
Yes, the integration works well with ITOM modules including Event Management for alert correlation, Service Mapping for topology awareness, and Operational Intelligence for advanced analytics. You can map ThousandEyes network path data to ServiceNow's service topology to provide automated impact assessment when network issues affect business services. Health Log Analytics can process ThousandEyes performance metrics for trend analysis and predictive alerting, while Discovery can be enhanced with ThousandEyes network topology data for comprehensive infrastructure visibility.
How can I customize incident priority and assignment based on ThousandEyes test criticality?
Implement business logic in your webhook processing script that evaluates ThousandEyes alert metadata such as test names, affected locations, or custom test tags to determine appropriate ServiceNow priority levels and assignment groups. You can maintain mapping tables in ServiceNow that correlate ThousandEyes test IDs or test name patterns to specific teams, escalation procedures, or SLA requirements. Consider using ServiceNow's Assignment Rules or Flow Designer to create sophisticated routing logic based on network performance thresholds, time of day, or business impact classifications derived from ThousandEyes alert context.
Is it possible to trigger ThousandEyes tests or maintenance modes from ServiceNow Change Management?
Yes, you can implement bidirectional integration by creating outbound REST calls from ServiceNow Change Management workflows to the ThousandEyes API for enabling maintenance modes or triggering on-demand tests during change windows. Use business rules on Change Request records to automatically suppress ThousandEyes alerting during approved maintenance periods by calling the ThousandEyes alert suppression API. Flow Designer can orchestrate complex scenarios where change approvals trigger specialized ThousandEyes test configurations to validate network changes before and after implementation, providing automated change verification capabilities.
What happens to ServiceNow incidents if the ThousandEyes API becomes unavailable for enrichment calls?
Implement proper error handling in your enrichment business rules to gracefully handle ThousandEyes API unavailability by creating incidents with basic webhook data and marking them for later enrichment retry. Use Try-Catch blocks in your JavaScript code to prevent API failures from blocking incident creation, and consider implementing a retry queue using ServiceNow's scheduled jobs to attempt enrichment at regular intervals. You can also configure fallback notification workflows to alert administrators when API enrichment fails consistently, ensuring that network monitoring incidents are still created and processed even when detailed ThousandEyes data is temporarily unavailable.
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