Discovery Schedules are not running if the previous schedule gets canceled

[ruha_joshi]

Discovery schedules are not triggering as expected when the previous discovery schedule is canceled, despite the "Even if canceled" option being enabled in the schedule configuration. Based on the expected behavior, subsequent discovery schedules should continue to execute regardless of whether the previous schedule completed successfully or was canceled. However, the next scheduled discovery does not start, resulting in missed discovery runs.

[Vikram Reddy]

Hi @ruha_joshi 

The behavior you are describing is not how "Run after" is documented to work, so this is worth treating as a stuck-state problem rather than a configuration problem. Per ServiceNow's own documentation on discovery schedule run options, a schedule configured to run after another one will not fire unless the prior schedule either completes or is canceled, and if "Even if canceled" is checked it should fire once that prior schedule reaches a canceled state. The key phrase is "reaches a canceled state." In every case I have run into where this silently stops working, the upstream discovery never actually got there.

When you cancel a running discovery (manually, via Max Run Time, or via the "no progress detected" watchdog), the Discovery Status record has to transition all the way through to a final Cancelled state before the "Run after" check on the next schedule will evaluate as true. If the MID Server never acknowledges the cancel signal (backed-up ECC queue, a probe/sensor still writing back, a cluster with a lot of concurrent work), the status record can sit indefinitely in an interim state instead of landing on Cancelled. From the schedule engine's point of view, that upstream run never finished and was never canceled, so the downstream schedule with "Even if canceled" checked has nothing to react to and just never starts. This matches what other admins have reported with discoveries stuck in an active state before eventually cancelling, and with runs cancelled with reasons like "No progress was detected on status" that leave things in an ambiguous state.

To confirm this is what's happening in your instance:

1. Open the Discovery Status record for the run that was canceled and check the State field directly, don't rely on the schedule's "last run" summary. If it is not sitting on a clean Cancelled value, that is your answer.
2. Check the ECC Queue for that run's sys_id around the cancellation time. Input/output records still sitting there or stuck in "ready"/"processing" are a sign the MID Server never closed the run out.
3. Confirm the "Run after" reference on the downstream schedule still points at the correct, current upstream schedule sys_id. Cloned instances and schedule renames/recreations can leave this pointing at a stale record, which produces the exact same symptom.
4. Check the MID Server logs and load for the window in question. Overloaded or clustered MID Servers that are slow to process the cancel command are the most common reason a run hangs instead of cleanly closing.
5. Pull system logs around the cancellation timestamp for script errors on the discovery schedule business rules. A silent script error on the completion/cancel handler will stop the chain without any obvious symptom on the schedule form itself.

As an immediate workaround, once you've confirmed the upstream run is functionally dead (not actually going to progress further), you can manually trigger the downstream schedule rather than waiting on the chain, and separately open a case with ServiceNow support referencing the Discovery Status record so they can trace why that specific run didn't reach Cancelled. If this is happening repeatedly rather than as a one-off, it's usually a MID Server capacity or ECC queue backlog issue, not something you can fix from the schedule configuration alone.

For reference on the documented run option behavior, see Run options for discovery schedules, and for the pattern of runs getting stuck before reaching a final state, see this community thread on Discovery schedules getting stuck and this one on Discovery cancelled with reason "No progress was detected on status".

Thank you,
Vikram Karety
Octigo Solutions INC