ServiceNow Discovery Schedule Explained

What Discovery Schedule Does

Discovery Schedule controls when and how often ServiceNow automatically scans your networks and systems to find configuration items and update your CMDB. A schedule might run network scans every night at midnight, or database discovery every Monday morning. The schedule determines whether ServiceNow keeps your CMDB in sync with your actual infrastructure or whether your CMDB becomes stale between manual refresh cycles.

Without a discovery schedule, you manually run discovery probes when you think about it or when someone reminds you. Infrastructure changes between discovery runs are not captured. New servers, removed assets, configuration changes all happen without ServiceNow knowing. A discovery schedule automates this so your CMDB stays current automatically.

How Discovery Schedules Work

Each discovery probe (network scan, database query, application probe) can have its own schedule. You define the frequency: hourly, daily, weekly, monthly. You define when the scan should run: a business day at 2 AM, or every Sunday night. The schedule includes retry logic in case a scan fails, so a failed scan is retried before you declare it unsuccessful.

The schedule also includes execution limits. If a discovery probe takes two hours to complete, you might schedule it to run once per day rather than every four hours. Multiple concurrent discovery probes can consume significant CPU and network bandwidth. ServiceNow lets you configure how many probes run simultaneously, so discovery does not overwhelm your infrastructure or your monitored systems.

A Worked Example

Your network contains two hundred servers. You configure a network discovery schedule to scan your IP ranges every night at 2 AM, looking for new servers, decommissioned servers, and servers that have changed IP addresses. The discovery probe takes thirty minutes to complete. Every morning, you wake up to updated CMDB data that reflects your current infrastructure.

In parallel, you schedule a Windows system discovery at an interval set by how often your servers change. This probe logs into servers using service accounts and reads Windows registry and WMI data to discover installed applications and system configuration. Application discovery runs at an interval that matches how often deployments change, querying your application deployment database for deployed versions and linking them to the servers where they run.

If a discovery probe fails, the schedule retry logic runs it again the following night. If it fails twice, an alert is created so your team can investigate. This automated retry prevents temporary network issues or authentication problems from causing permanent gaps in your CMDB.

Performance and Operational Impact

Discovery scans consume CPU on the systems being scanned and network bandwidth. Heavy scanning at 9 AM during business hours might affect application performance. Scheduling discovery outside business hours, typically between 11 PM and 6 AM, minimizes impact. Stagger probes so not all of them run at the same time.

The MID Server running discovery also consumes CPU and memory. Monitor resource utilization during scheduled discovery runs. If your MID Server is saturated, spread discovery probes across multiple MID Servers or reduce discovery frequency. A MID Server that is busy discovering infrastructure cannot handle monitoring or integrations.

Common Schedule Patterns

Network discovery is often run frequently, finding newly added servers and decommissioned systems quickly. Host-level discovery can run less often; more frequent scanning is unnecessary if system configurations change slowly and your environment is relatively stable. Application discovery often runs less often than network discovery because application changes are planned and less frequent than infrastructure changes. You can adjust these schedules based on how quickly your environment changes, your risk tolerance for stale data, and the compute capacity available for running discovery probes during your preferred time windows.

The first discovery scan in your environment takes longest because there is much to discover. Subsequent discovery runs are typically faster because only changed items are updated. Plan for initial discovery to take longer than ongoing scans.

Why the schedule is a capacity decision, not only a freshness decision

Teams often set a discovery schedule to keep the configuration data current, and that goal is right. The harder part is that every scheduled probe draws on the same finite resources: the MID server that runs it, the network path to the target, the service account that authenticates to the target, and the target’s own tolerance for scanning. When two probes that touch the same subnet or the same accounts start together, the result is slow runs, failed logins and a configuration record that is missing the very items the schedule was meant to find. A useful schedule starts from the question of which resources each probe needs and when they are free, and only then asks how often the data should refresh.

Matching cadence to the kind of change being tracked

Introducing a new schedule without disrupting the estate

1. List every probe that will run from the MID server and the target ranges each one touches. Two probes sharing a range need separate windows.
2. Check with the owner of each target whether the scan window falls inside any change freeze or batch processing period, and record the answer.
3. Stagger the start times so that the busiest probes do not begin together, and cap concurrency at the MID server if the platform setting allows it.
4. Run the schedule once manually against a small range, then review the run history for failed credentials and slow hosts before extending the range.
5. Enable the recurring schedule and check the first full cycle, not only the first run.

Failures that look like discovery problems but are not

When a schedule seems to stop finding things, the cause is often outside discovery. Credentials that fail repeatedly can lock the service account on the target, which then breaks monitoring and backups that share the same account. A retry policy that reruns a failed probe immediately, every time, can produce a burst of failed logins that looks like an attack to the security team. A MID server with a full work queue can accept the schedule and process it late, so the run appears to succeed while the data arrives hours after the change it describes. Read the failure reasons in the run history before you change the schedule, and separate authentication faults from network faults from timeouts.

Reading a run history that tells you something

A run history with only green and red entries hides the information you need. For each probe, look at how many items were found, how many were new, how many changed and how many were removed. A probe that reports zero changes week after week is either tracking a stable estate or failing to see the part of the estate where change happens. Compare the item counts against a manual check of one or two target ranges. If the counts diverge, the schedule is not the problem yet; the scope of the probe is.

When not to schedule a probe at all

Some targets are fragile enough that an unattended scan does more harm than good, such as older industrial controllers or systems that do not handle high connection rates well. For those, run discovery on demand, under supervision, during an agreed window, and record the outcome. Scheduling them creates a false sense of coverage. The same reasoning applies to a new network segment that has not been assessed for scan impact. Start with a manual run and promote it to a schedule only after the owner signs off.

Frequently asked questions about discovery schedules

Why does a scheduled probe finish faster after the first run?

The first run has to create every item it finds, while later runs mostly compare and update. That is why the first full discovery takes the longest, and why planning should allow for it rather than treating the first schedule as representative.

Should discovery run during business hours if the MID server is idle then?

An idle MID server does not mean the target is idle. Scans consume CPU and network on the systems being scanned, and users notice that more quickly than they notice a MID server queue. Choose windows based on the target’s load, not the MID server’s.

Who should be allowed to change a schedule?

Limit schedule edits to the CMDB or discovery owner, and require a note in the change record for any change to frequency, scope or concurrency. Silent edits are a common reason a schedule that worked for a year stops finding anything.

How do discovery schedules interact with reconciliation?

Discovery feeds identification and reconciliation, so a schedule that runs against a wider scope than the reconciliation rules expect can create duplicates. Review the scope and the reconciliation rules together whenever either one changes.

Next step

If the probe list grew one entry at a time, review the whole schedule together rather than probe by probe.