ServiceNow Discovery: How It Works and What It Actually Finds

Discovery troubleshooting framework

When Discovery runs but CIs are not appearing or updating correctly, diagnose in sequence. First: check the MID Server is online and recently checked in (Discovery > MID Servers). Second: verify the Discovery Schedule ran — check the Schedule History. Third: check the ECC Queue for errors on the MID Server's entries — filter by agent (your MID Server name) and look for error states. Fourth: check the Discovery Log (Discovery > Discovery Log) for probe-level errors — these show authentication failures, network timeouts, and unsupported OS/hardware. Fifth: verify the CI class and Identification Rules — if a device is discovered but appears as "unknown" rather than the expected CI class, the hardware identification rule may not match. The Discovery Log is the most useful diagnostic tool; learn to read it fluently before relying on the ServiceNow support team for Discovery issues.

Discovery Architecture: Probes and Sensors

Discovery uses a two-stage architecture to identify and classify infrastructure. Probes are outbound scripts executed by the MID Server that collect raw data from target devices — they might run a WMI query on a Windows server, an SNMP walk on a network device, or an SSH command on a Linux host. Sensors are the processing layer that receive probe results and transform raw output into structured CMDB records. A single Discovery run against a Windows server might execute a dozen probes covering OS details, installed software, network interfaces, and running services, with each probe result flowing into a corresponding sensor that creates or updates CI records in the appropriate CMDB tables.

IP Ranges and Discovery Schedules

Discovery is scoped to IP ranges defined in Discovery Schedules. Each schedule specifies one or more IP ranges, a MID Server to use, and a recurrence interval. For large environments, Discovery Schedules are typically segmented by network segment, data centre, or environment type (production vs non-production). This segmentation serves two purposes: it controls which MID Server handles which traffic (important for network segmentation and firewall rules), and it lets you tune discovery frequency independently — production infrastructure might run hourly while development environments run once per day. The Scheduled Jobs system underlies Discovery scheduling at the platform level.

Credentials and Authentication

Discovery requires credentials to authenticate against target devices. ServiceNow stores these in the Credentials module, which supports Windows (WMI/WinRM), SSH (password and key-based), SNMP (v1/v2c/v3), VMware, and cloud provider credentials. Credentials are associated with IP ranges or specific CIs, and the Discovery engine tries them in priority order. Using the Connection and Credential Aliases framework for Discovery credentials provides better governance than hard-coded credential assignments — the alias layer allows credential rotation without modifying Discovery configuration directly.

Reconciliation and CI Deduplication

One of the most operationally important aspects of Discovery is the reconciliation engine, which determines what to do when a discovered CI matches an existing record in the CMDB. The Identification and Reconciliation Engine (IRE) uses identification rules to match incoming discovery data against existing CIs, preventing duplicates. Identification rules specify which attributes constitute a unique identifier for a CI type — for servers, this is typically a combination of hostname, serial number, and MAC address. When multiple discovery sources find the same CI (for example, both network Discovery and a separate AWS integration reporting the same EC2 instance), the IRE merges the data according to precedence rules. The CMDB guide covers the full IRE configuration in detail.

Horizontal Discovery vs Service Mapping

Standard Discovery is horizontal — it scans IP ranges and discovers individual CIs in isolation. Service Mapping is a separate, complementary capability that discovers application services by tracing connections between CIs from a defined entry point (typically a URL or IP). Where Discovery tells you "this server exists with these attributes," Service Mapping tells you "these five servers, two load balancers, and one database together constitute the Order Management application." The two are complementary: Discovery populates the CMDB with accurate CI data, and Service Mapping builds the relationship layer on top of that data. Both rely on the MID Server as the execution layer.

Troubleshooting Discovery Failures

Discovery failures fall into a few categories. Credential failures produce "Authentication failed" errors in the Discovery log and mean the stored credential does not match what the target device accepts. Network failures (timeouts, unreachable hosts) indicate either firewall rules blocking the MID Server's outbound traffic or the target device being offline. Sensor failures occur when a probe returns data the sensor cannot parse — typically because the target OS version or software version returns output in an unexpected format. All Discovery activity is logged in the Discovery Log (discovery_log table), filterable by status and MID Server. The instance troubleshooting guide covers log analysis patterns applicable to Discovery log review.

Pattern-Based Discovery for Custom Applications

ServiceNow ships with discovery patterns for common software (Apache, Tomcat, Oracle, SQL Server), but custom enterprise applications require custom patterns. A discovery pattern for a custom application defines how to detect the application's presence on a server (a specific process name or port) and what data to collect once detected (version from a log file, configuration from a properties file, connection endpoints from a config). Pattern development requires understanding both the ServiceNow pattern language and the target application's installation layout. For organisations with homegrown applications, investing in custom discovery patterns is the only way to achieve accurate CMDB coverage — manually maintained application CIs are almost always out of date within months of the last audit.

Cloud Discovery and CMDB Population

Modern infrastructure spans physical data centres and cloud providers, requiring Discovery to cover both. ServiceNow's Cloud Discovery connects to AWS, Azure, and GCP APIs to enumerate compute instances, load balancers, storage, and networking resources, populating the CMDB with cloud CIs and their relationships. Cloud Discovery differs from network Discovery in that it uses API calls rather than network scanning — no MID Server reaches into the cloud network; instead, cloud credentials allow the instance to query provider APIs directly. Cloud CIs discovered this way sync regularly (configurable interval) with the provider's current state, providing near-real-time CMDB accuracy for cloud infrastructure that physical Discovery cannot match for on-premises equipment. The Credential Aliases framework manages cloud provider API credentials.

Discovery Scheduling for Operational Efficiency

Running Discovery continuously against all devices wastes MID Server resources and generates unnecessary CMDB churn. Structure Discovery schedules by change rate: physical servers that rarely change run weekly or daily; virtual machines and cloud instances that change frequently run hourly or every few hours; network devices run daily unless your environment has rapid provisioning cycles. Set the scan interval at the minimum frequency needed to keep CMDB data current for your change management process — too frequent creates noise, too infrequent creates stale data. For environments with formal change management, aligning post-change Discovery scans with the change window ensures CMDB reflects approved changes within hours of implementation rather than waiting for the next scheduled scan cycle. The scheduling guide covers the underlying platform mechanisms Discovery scheduling uses.