ServiceNow Docker integration enables organizations to automatically discover containerized infrastructure as Configuration Items (CIs), monitor Docker registry events, track container health through Event Management, and orchestrate container lifecycle workflows. This integration solves the critical challenge of maintaining visibility and governance over dynamic containerized environments where containers are ephemeral and traditional discovery methods fall short. The integration serves DevOps teams, infrastructure engineers, and IT operations managers who need centralized visibility into Docker deployments across their enterprise. Data flows bidirectionally between Docker environments and ServiceNow, with Docker API calls pulling container metadata and registry webhooks pushing deployment events in real-time. The primary automation pattern involves event-driven discovery triggered by container lifecycle changes, registry push/pull events, and scheduled health checks, with core functionality residing in the Service Mapping, Event Management, and Configuration Management modules.
Prerequisites
- •ServiceNow Rome release or later with Discovery and Service Mapping plugins activated
- •Integration Hub Professional license or higher for Docker-specific spokes and orchestration workflows
- •MID Server with network connectivity to Docker daemon endpoints and container registries
- •Docker Engine API v1.40 or later with API access enabled on target Docker hosts
- •Docker Hub Pro account or private container registry with webhook capability for real-time event integration
- •Event Management plugin activated for container health monitoring and alerting
- •Configuration Management Database (CMDB) with proper CI class definitions for containerized infrastructure
Architecture Overview
The ServiceNow Docker integration leverages the Integration Hub Docker spoke along with custom REST integrations to establish comprehensive container visibility and management. Authentication is handled through Connection and Credential Aliases stored in ServiceNow, supporting Docker API tokens, registry credentials, and TLS certificates for secure daemon communication. Data flows bidirectionally with outbound REST calls via RESTMessageV2 objects pulling container metadata, image information, and health status, while inbound webhook endpoints receive registry events and deployment notifications. A MID Server is required to access Docker daemon APIs within private networks and perform discovery scans, as the ServiceNow instance cannot directly reach internal Docker hosts due to network security constraints. API rate limiting considerations include Docker Hub's 200 pulls per 6-hour period for anonymous users and 5000 pulls for authenticated users, requiring careful orchestration of discovery schedules and credential management to avoid throttling.
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
Configure Docker API credentials in ServiceNow Connection & Credential Aliases
Navigate to Connections & Credentials > Credentials and create a new Basic Authentication credential record with your Docker registry username and access token. Set the credential name to 'docker_registry_auth' and ensure the password field contains your Docker Hub access token or private registry API key. For Docker daemon API access, create an additional credential of type 'SSH Private Key' if using TLS client certificates, storing the client certificate and private key. Test the credential by clicking the 'Test Credential' button to verify connectivity. Common mistakes include using your Docker Hub password instead of an access token, which will result in authentication failures due to Docker's deprecation of password-based API access.
Create Connection Alias for Docker daemon and registry endpoints
Navigate to Connections & Credentials > Connection Aliases and create a new alias named 'docker_daemon_connection' with the connection URL pointing to your Docker daemon endpoint (typically https://your-docker-host:2376 for TLS or http://your-docker-host:2375 for unencrypted). Associate the credential created in step 1 with this connection alias and configure any required HTTP headers such as 'Content-Type: application/json'. Create a second connection alias named 'docker_registry_connection' pointing to your Docker registry API endpoint (https://registry-1.docker.io for Docker Hub or your private registry URL). Set connection timeout values appropriately, typically 30 seconds for daemon operations and 60 seconds for registry operations which may involve larger payloads. Verify both connections show 'Active' status and test connectivity using the built-in connection test feature.
Install and configure the Integration Hub Docker spoke
Navigate to System Applications > All Available Applications > All and search for 'Docker' to locate the official Docker spoke in the ServiceNow Store. Install the Docker spoke which provides pre-built actions for container discovery, image management, and health monitoring. After installation, navigate to Process Automation > Flow Designer and create a new flow called 'Docker Container Discovery Flow' using the Docker spoke actions. Configure the Docker spoke connection by editing the spoke configuration to reference your connection aliases from step 2. The spoke provides actions like 'List Containers', 'Inspect Container', 'Get Container Stats', and 'Pull Image Information' which form the foundation for automated discovery and monitoring workflows. Test each action individually in Flow Designer to ensure proper connectivity and data retrieval before proceeding to full workflow implementation.
Configure CI classes and identification rules for Docker containers
Navigate to Configuration > CI Class Manager and extend the existing 'Computer' CI class to create a new class called 'Docker Container' with attributes for container ID, image name, image tag, port mappings, volume mounts, and resource limits. Define identification rules by navigating to Configuration > Identification and Reconciliation > Identification Rules and creating rules that use container ID as the primary identifier and image name as a secondary identifier. Set up dependency mapping rules to establish relationships between containers, images, and host systems by configuring relationship types in the CI Relationship Type table. Add custom attributes to capture Docker-specific metadata such as network settings, environment variables, and restart policies. Ensure the CI class hierarchy properly reflects the containerized infrastructure topology with relationships between Docker hosts, containers, images, and associated applications or services.
Create REST Message and HTTP Methods for Docker API integration
Navigate to System Web Services > Outbound > REST Messages and create a new REST Message record named 'Docker API Client' with the endpoint URL using variable substitution like 'https://${docker_host}:2376${api_path}'. Create individual HTTP Methods for each Docker API endpoint you need to consume: 'list_containers' (GET /containers/json), 'inspect_container' (GET /containers/${container_id}/json), 'container_stats' (GET /containers/${container_id}/stats), and 'list_images' (GET /images/json). Configure authentication by setting the HTTP method authentication type to use your connection alias from step 2, and add required HTTP headers including 'Accept: application/json'. Set proper timeout values and configure response parsing to handle Docker API JSON responses. Test each HTTP method individually using the 'Test' link to verify API connectivity and response format before integrating into discovery scripts.
var rm = new sn_ws.RESTMessageV2('Docker API Client', 'list_containers');
rm.setStringParameterNoEscape('docker_host', 'docker-prod-01.company.com');
rm.setStringParameterNoEscape('api_path', '/containers/json?all=true');
rm.setRequestHeader('Content-Type', 'application/json');
var response = rm.execute();
var httpStatus = response.getStatusCode();
var responseBody = response.getBody();
if (httpStatus == 200) {
var containers = JSON.parse(responseBody);
gs.info('Found ' + containers.length + ' containers');
return containers;
} else {
gs.error('Docker API call failed with status: ' + httpStatus);
return null;
}Implement container discovery scheduled job and CI population
Navigate to System Definition > Scheduled Jobs and create a new scheduled job named 'Docker Container Discovery' that runs every 15 minutes to discover and update container CIs. Write a script that uses your REST Message from step 5 to query Docker APIs, parse container information, and create or update CI records in the cmdb_ci_docker_container table. Implement logic to handle container lifecycle events by comparing current API results with existing CIs, marking stopped containers as 'Retired' and creating new CIs for recently started containers. Include error handling for API timeouts, authentication failures, and network connectivity issues. Configure the job to run on your MID Server to ensure network access to Docker daemon endpoints, and set up logging to track discovery statistics and any errors encountered during the process.
var DockerDiscovery = Class.create();
DockerDiscovery.prototype = {
initialize: function() {
this.containerTable = 'cmdb_ci_docker_container';
this.imageTable = 'cmdb_ci_docker_image';
},
discoverContainers: function(dockerHost) {
var rm = new sn_ws.RESTMessageV2('Docker API Client', 'list_containers');
rm.setStringParameterNoEscape('docker_host', dockerHost);
var response = rm.execute();
if (response.getStatusCode() == 200) {
var containers = JSON.parse(response.getBody());
for (var i = 0; i < containers.length; i++) {
this.processContainer(containers[i], dockerHost);
}
}
},
processContainer: function(containerData, dockerHost) {
var gr = new GlideRecord(this.containerTable);
gr.addQuery('container_id', containerData.Id);
gr.query();
if (!gr.next()) {
gr.initialize();
gr.container_id = containerData.Id;
}
gr.name = containerData.Names[0].substring(1);
gr.image = containerData.Image;
gr.status = containerData.Status;
gr.docker_host = dockerHost;
gr.ports = JSON.stringify(containerData.Ports);
gr.update();
},
type: 'DockerDiscovery'
};Configure Docker registry webhooks for real-time event integration
Navigate to System Web Services > Inbound > Scripted REST APIs and create a new API named 'Docker Registry Webhook Handler' with a resource path of '/docker/registry/events'. Implement POST method handling to receive webhook payloads from Docker Hub or your private registry when images are pushed, pulled, or deleted. Parse the incoming webhook JSON payload to extract repository information, tag details, and action type, then create corresponding Event Management records or trigger automated deployment workflows. Configure your Docker registry (Docker Hub, Harbor, or AWS ECR) to send webhooks to your ServiceNow instance endpoint: https://your-instance.service-now.com/api/your-namespace/docker/registry/events. Set up proper authentication for the webhook endpoint using API key validation or IP address whitelisting to ensure only legitimate registry events are processed. Test the webhook integration by pushing a test image to your registry and verifying that the corresponding event is created in ServiceNow.
(function process(/*RESTAPIRequest*/ request, /*RESTAPIResponse*/ response) {
var payload = request.body.data;
var action = payload.action;
var repository = payload.target.repository;
var tag = payload.target.tag;
gs.info('Docker registry webhook received: ' + action + ' for ' + repository + ':' + tag);
// Create event management record
var eventGr = new GlideRecord('em_event');
eventGr.initialize();
eventGr.source = 'Docker Registry';
eventGr.type = 'docker.registry.' + action;
eventGr.resource = repository;
eventGr.node = payload.request.host;
eventGr.description = 'Docker image ' + action + ': ' + repository + ':' + tag;
eventGr.severity = (action == 'push') ? 1 : 2;
eventGr.insert();
// Trigger container discovery for push events
if (action == 'push') {
gs.eventQueue('docker.image.pushed', eventGr, repository, tag);
}
response.setStatus(200);
response.setBody(JSON.stringify({status: 'processed', action: action}));
})(request, response);Set up Event Management rules and container health monitoring
Navigate to Event Management > Event Rules and create rules to process Docker-related events for container health monitoring, resource utilization alerts, and deployment notifications. Configure event correlation rules to group related container events and prevent alert storms during rolling deployments or batch container operations. Create alerting policies that escalate critical container failures to incident records and notify DevOps teams through ServiceNow notifications or external channels like Slack. Set up scheduled health checks by extending your discovery job to collect container resource metrics (CPU, memory, network) via the Docker stats API and create events when thresholds are exceeded. Implement automated remediation workflows in Flow Designer that can restart failed containers, scale container replicas, or trigger deployment rollbacks based on event patterns and business rules. Test the complete monitoring pipeline by simulating container failures and verifying that events are properly correlated, alerts are generated, and incidents are created according to your defined escalation policies.
// Event Rule Script for Docker Container Health Events
if (event.type == 'docker.container.unhealthy') {
var containerName = event.resource;
var dockerHost = event.node;
// Check if container is critical (tagged with critical=true label)
var containerGr = new GlideRecord('cmdb_ci_docker_container');
containerGr.addQuery('name', containerName);
containerGr.addQuery('docker_host', dockerHost);
containerGr.query();
if (containerGr.next()) {
var labels = JSON.parse(containerGr.labels || '{}');
if (labels.critical == 'true') {
// Create high priority incident for critical containers
var incGr = new GlideRecord('incident');
incGr.initialize();
incGr.short_description = 'Critical Docker container unhealthy: ' + containerName;
incGr.description = 'Docker container ' + containerName + ' on host ' + dockerHost + ' is reporting unhealthy status';
incGr.priority = 1;
incGr.assignment_group = 'DevOps Team';
incGr.cmdb_ci = containerGr.sys_id;
incGr.insert();
// Trigger automated restart workflow
gs.eventQueue('docker.container.restart', incGr, containerName, dockerHost);
}
}
}Common Use Cases
Automated Container CI Discovery and CMDB Population
This use case involves scheduled discovery jobs that automatically scan Docker daemon APIs across multiple hosts to identify running containers and populate the CMDB with container configuration items. The discovery process captures container metadata including image information, port mappings, volume mounts, environment variables, and resource constraints, creating comprehensive CI records that reflect the current state of containerized infrastructure. ServiceNow maintains relationships between containers, host systems, images, and dependent applications, enabling impact analysis and change management workflows. The business value includes eliminating manual container inventory processes, ensuring CMDB accuracy for containerized environments, and providing visibility into shadow IT containerized deployments.
Docker Registry Event-Driven Deployment Tracking
Real-time webhook integration with Docker registries triggers automated workflows when container images are pushed, pulled, or deleted, creating audit trails and initiating deployment processes. Registry events automatically update image CI records, track version changes, and can trigger security scanning workflows or compliance validation processes based on image tags or repository names. ServiceNow creates deployment records linking registry events to container updates and maintains a complete history of image lifecycle events across development, staging, and production environments. This provides DevOps teams with centralized visibility into deployment pipelines and enables automated change approval processes based on image promotion policies.
Container Health Monitoring and Incident Management
Continuous monitoring of container health status, resource utilization, and performance metrics through Docker API integrations feeds into ServiceNow Event Management for real-time alerting and incident creation. Health check failures, resource threshold breaches, and container restart events automatically generate events that are correlated and escalated to incidents based on business impact and service criticality. The system maintains historical performance data for capacity planning and can trigger automated remediation workflows including container restarts, resource scaling, or deployment rollbacks. Business value includes reduced mean time to detection for container issues, automated incident response for critical services, and proactive capacity management for containerized applications.
Container Lifecycle Change Management and Approval Workflows
Integration enables automated change management processes for container deployments, image updates, and infrastructure modifications by detecting container lifecycle events and routing them through appropriate approval workflows. Changes such as new container deployments, image version updates, or configuration modifications trigger change requests with auto-populated technical details and impact assessments based on CMDB relationships. ServiceNow can enforce deployment policies by blocking unauthorized image deployments, requiring approvals for production changes, and maintaining compliance audit trails for containerized environments. This provides governance over dynamic container environments while enabling DevOps velocity through automated approval processes for low-risk changes.
Security Vulnerability Management for Container Images
Registry webhook events trigger automated security scanning workflows that integrate with vulnerability assessment tools to identify security issues in newly pushed container images. ServiceNow creates vulnerability records linked to specific image versions and tracks remediation efforts across all deployed instances of vulnerable images. The system can automatically quarantine vulnerable images, block deployments of images with critical vulnerabilities, and generate security incidents requiring immediate attention. Business value includes proactive security posture management, automated compliance reporting for container security, and reduced exposure to security vulnerabilities in production containerized applications through policy-driven image lifecycle management.
Troubleshooting
Docker API calls return 401 Unauthorized errors despite valid credentials
First, verify that your Docker daemon is configured to accept API connections by checking the daemon startup parameters include '-H tcp://0.0.0.0:2376' for TLS or '-H tcp://0.0.0.0:2375' for unencrypted access. Check the ServiceNow Connection Alias configuration to ensure the credential is properly associated and test the credential independently using the 'Test Credential' feature. For TLS-enabled Docker daemons, verify that the client certificates are valid and properly formatted in the credential record, and ensure the ServiceNow MID Server has network connectivity to the Docker daemon port. Review the Docker daemon logs for authentication failures and check that any IP-based access controls allow connections from the MID Server IP address.
Container discovery job runs successfully but no CI records are created or updated
Check the Discovery log and scheduled job history for any script errors or exceptions that might prevent CI creation. Verify that the cmdb_ci_docker_container table exists and has the required custom fields by navigating to System Definition > Tables and reviewing the table schema. Review the identification rules for Docker container CIs to ensure they're properly configured to match on container ID or other unique identifiers. Check the user permissions for the scheduled job execution context to ensure it has write access to CMDB tables and can create CI records. Enable debug logging in your discovery script to trace the data flow and verify that container data is being parsed correctly from Docker API responses.
Docker registry webhooks are not triggering ServiceNow events or workflows
Verify that the registry webhook URL is correctly configured and points to your ServiceNow instance endpoint, ensuring the correct namespace and API path are specified. Test the webhook endpoint directly using a REST client tool like Postman to confirm it's accessible and responding with 200 status codes. Check the ServiceNow application logs and system logs for any errors processing incoming webhook requests, and verify that the Scripted REST API has proper error handling for malformed payloads. Confirm that the registry is actually sending webhooks by checking the registry webhook delivery logs (available in Docker Hub webhook settings or private registry admin interfaces) and ensure any required authentication headers or tokens are properly configured.
MID Server cannot connect to Docker daemon endpoints despite network connectivity
Verify that the Docker daemon is listening on the expected network interface and port by running 'netstat -tlnp | grep :2376' on the Docker host to confirm the daemon is bound to the correct address. Check that any firewalls or security groups between the MID Server and Docker hosts allow traffic on the Docker daemon port (typically 2375 for HTTP or 2376 for HTTPS). For TLS-enabled Docker daemons, ensure the client certificates configured in ServiceNow match those expected by the Docker daemon and verify certificate validity and chain. Test connectivity from the MID Server host directly using curl or Docker CLI commands to isolate whether the issue is network-related or ServiceNow configuration-related.
Event Management rules not processing Docker events or creating incorrect alert severity levels
Review the Event Management event processing logs to identify any rule execution errors or condition matching failures. Check that event field mappings are correctly extracting data from Docker webhook payloads and API responses, particularly source, type, resource, and node fields used for correlation. Verify that event rules are ordered correctly and not being bypassed by earlier rules that consume or transform events before Docker-specific rules can process them. Test event rule logic by manually creating test events with known values and observing the rule execution results, adjusting condition logic and field mappings as needed to properly classify and route Docker-related events.
Container health metrics showing stale data or not updating despite active containers
Check the Docker stats API endpoint response time and configure appropriate timeout values in your REST Message configuration, as stats collection can be resource-intensive and may require longer timeouts. Verify that your scheduled discovery job frequency is appropriate for your monitoring requirements while avoiding Docker API rate limits that could cause throttling. Review the container stats data parsing logic to ensure all relevant metrics are being extracted and stored in the correct CI fields, and check for any data type conversion errors that might prevent metric updates. Consider implementing differential updates that only collect stats for containers that have changed since the last discovery run to improve performance and reduce API load.
Pro Tips
- →Implement container CI retirement logic that automatically marks container CIs as 'Retired' when containers are removed from Docker hosts, preventing CMDB bloat from ephemeral containers. Use GlideDateTime to compare last discovery timestamps and retire CIs that haven't been seen for a configurable period.
- →Leverage Docker labels as a metadata source for ServiceNow CI classification and assignment group routing by parsing container labels during discovery and mapping them to ServiceNow fields. This enables teams to embed ServiceNow-specific metadata directly in their Docker deployments.
- →Configure separate MID Server capabilities for different Docker environment tiers (dev, staging, production) to isolate credentials and control discovery scope. This prevents accidental cross-environment data leakage and enables environment-specific monitoring policies.
- →Use ServiceNow's Import Set functionality for bulk container data processing when dealing with large-scale container environments, as it provides better performance and error handling than individual GlideRecord operations for high-volume discovery scenarios.
- →Implement event deduplication and correlation windows for container restart events to prevent alert storms during rolling deployments or batch operations, using Event Management's built-in correlation rules to group related container lifecycle events.
- →Create custom notification schemes that integrate with ChatOps platforms like Slack or Microsoft Teams for real-time container event notifications, allowing DevOps teams to receive alerts in their preferred communication channels while maintaining ServiceNow as the system of record.
Known Limitations
- —Docker Hub API rate limiting restricts anonymous users to 100 pulls per 6 hours and authenticated users to 200 pulls per 6 hours, requiring careful orchestration of discovery schedules and credential rotation to avoid throttling in large-scale environments. Consider using Docker Hub Pro accounts or private registries for higher rate limits.
- —ServiceNow's RESTMessageV2 has a default response size limit of 10MB which can be exceeded when collecting detailed container statistics or large image manifests, requiring custom payload filtering or pagination logic. Long-running container stats streams must be handled carefully to avoid memory issues.
- —MID Server deployment is mandatory for Docker daemon API access in most enterprise environments due to network security constraints, adding infrastructure complexity and potential single points of failure. Plan for MID Server high availability and credential rotation procedures.
- —Container discovery frequency is limited by Docker API performance and network latency, making true real-time container inventory challenging for dynamic environments with frequent container lifecycle changes. Typical discovery intervals of 5-15 minutes may miss short-lived containers or rapid scaling events.
- —ServiceNow's out-of-box CI class structure may not accommodate all Docker-specific metadata without customization, requiring schema modifications and custom identification rules that can complicate platform upgrades. Consider using JSON fields for flexible metadata storage while maintaining structured data for key attributes.
Frequently Asked Questions
Can ServiceNow integrate with container orchestration platforms like Kubernetes alongside direct Docker integration?
Yes, ServiceNow provides separate Integration Hub spokes for Kubernetes and Docker that can work together to provide comprehensive container visibility. The Kubernetes spoke handles cluster-level resources like pods, services, and deployments, while the Docker spoke focuses on individual container details and image management. You can correlate Kubernetes pod CIs with their underlying Docker container CIs through relationship mapping. Many organizations implement both integrations to get complete visibility from orchestration layer down to individual containers, though this requires careful CI design to avoid duplication.
How does ServiceNow handle container networking and service discovery in Docker Swarm or standalone Docker environments?
ServiceNow can capture Docker network configurations through the Docker API including bridge networks, overlay networks, and custom network definitions, storing this information as network CI relationships. For Docker Swarm, the integration can discover service definitions and map them to underlying container instances across multiple hosts. However, ServiceNow doesn't provide real-time service discovery capabilities like Consul or etcd - it maintains a point-in-time snapshot of network topology based on discovery intervals. Consider integrating with dedicated service discovery tools if you need dynamic service routing information within ServiceNow.
What happens to ServiceNow CI relationships when containers are destroyed and recreated with the same name but different container IDs?
ServiceNow handles this common Docker scenario through configurable identification rules that can use container names, image references, or custom labels as primary identifiers instead of ephemeral container IDs. When a container is recreated, the identification engine can match it to an existing CI record based on these stable identifiers and update the record with the new container ID. You can also implement custom logic in discovery scripts to handle container lifecycle events gracefully, preserving historical data and relationships while updating current configuration details. This prevents CMDB fragmentation from container churn in dynamic environments.
Can ServiceNow automatically trigger Docker container operations like restart, stop, or scale based on events or incidents?
Yes, ServiceNow can trigger Docker operations through Integration Hub flows or custom REST Message calls to Docker daemon APIs when certain events or incidents occur. The Docker spoke includes actions for container lifecycle management that can be orchestrated through Flow Designer workflows triggered by Event Management rules or incident assignment. However, this requires careful security consideration as it gives ServiceNow administrative control over production containers. Many organizations implement approval workflows for automated container operations and restrict automated actions to non-production environments or specific use cases like health check recovery.
How does the Docker integration handle container image security scanning and vulnerability management?
ServiceNow's Docker integration can trigger external security scanning tools through webhook events when new images are pushed to registries, but it doesn't include built-in vulnerability scanning capabilities. You can integrate with tools like Twistlock, Aqua, or Anchore by configuring workflows that call their APIs when container events occur, then import vulnerability results as Security Incident Response records or Vulnerability Response items. The integration maintains relationships between image CIs and vulnerability records, enabling impact analysis across all containers using vulnerable images. Consider using ServiceNow's Vendor Risk Management or Integrated Risk Management modules for comprehensive vulnerability lifecycle management.
What performance impact should I expect from enabling comprehensive Docker discovery and monitoring in ServiceNow?
Docker discovery performance depends on environment size, API response times, and discovery frequency, with typical impacts including increased MID Server resource utilization and higher API call volumes to Docker endpoints. Large environments with thousands of containers may require multiple MID Servers and optimized discovery scripts that use bulk operations rather than individual API calls. Registry webhook processing is generally lightweight, but high-volume deployment environments may need event batching or async processing to prevent performance bottlenecks. Monitor MID Server memory usage, Docker API response times, and ServiceNow table growth to optimize discovery intervals and data retention policies for your specific environment scale.
Does ServiceNow support Docker container log aggregation and analysis for troubleshooting workflows?
ServiceNow doesn't provide native Docker log aggregation capabilities, but it can integrate with log management platforms like Splunk, Elastic, or Datadog to correlate container logs with incident and event data. You can configure workflows that automatically attach relevant log snippets to incident records or create deep links to log analysis dashboards when container-related incidents are created. The Integration Hub includes spokes for major log management platforms that can be triggered by Docker events to pull contextual log data. For comprehensive log analysis, consider maintaining ServiceNow as the workflow and ticketing system while leveraging specialized log platforms for actual log storage and analysis capabilities.
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