Discovery schedule monitoring uses system property glide.discovery.schedule_monitoring.stale_check_seconds, not a form field - Support and Troubleshooting

Discovery schedule monitoring uses system property glide.discovery.schedule_monitoring.stale_check_seconds, not a form field .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Issue Discovery schedules may remain in Active state with a started/completed count mismatch. The schedule never completes because the monitoring mechanism does not detect the stuck status within the default threshold.

Symptoms Discovery schedule shows started count higher than completed count (e.g. 13 started, 12 completed) Schedule remains in Active state indefinitely No errors in Discovery logs indicating a failure Schedule does not auto-close after expected timeframe Cause Discovery schedule monitoring is controlled by the system property glide.discovery.schedule_monitoring.stale_check_seconds (default 1200 seconds / 20 minutes), not by a field on the discovery_schedule form.

Two scheduled jobs monitor discovery status:

DiscoveryMonitoringJob (runs every 10 minutes) — calls findAndHandlePotentialStuckStatuses DiscoveryStatusCounterJob (runs every 1 minute) — calls processStatuses A status is considered stale when sys_updated_on is older than now minus stale_check_seconds, and expired at 2x that value.

When a mismatch is detected, the monitor cancels the stuck status, recomputes counters, and marks the schedule as Completed. However, any probe data associated with the stuck status is lost and is NOT re-queued .

The completed counter increments in a finally block in DiscoverySensorJob.runSensor(), so post-processing script failures should NOT prevent the counter from incrementing.

Resolution Navigate to sys_properties.list and search for glide.discovery.schedule_monitoring.stale_check_seconds If the property exists, lower the value to catch stuck schedules faster (e.g. 600 seconds / 10 minutes) If the property does not exist, create it with the desired value To diagnose the stuck probe, query the ecc_queue table filtering by agent_correlator matching the stuck Discovery Status record When the monitor force-closes a schedule, the missing probe data is lost. If the data is critical, re-run discovery for the affected IP range Post-processing script failures should NOT cause counter mismatches. If you see a mismatch, the root cause is likely a probe that never returned from the MID Server