Adding a Max Runtime to Discoveries that were not triggered by Discovery SchedulesIssue Discovery Schedules can have a Max Runtime set, so that they will eventually be automatically cancelled if: it runs for longer than expected, and may run outside of its allowed time window, effecting performance of MID Server or the instance, or prevent the next 'run after' schedule in the sequence starting on time.it gets stuck and will never complete, perhaps because a Sensor crashed and the Started/Completed numbers will never add up and trigger the completion Discoveries triggered from UI Actions, or APIs, such as when Change Requests are updated, are not linked to Discovery Schedules, and so don't have any mechanism to timeout and auto-cancel at max runtime. The Discovery Status record remains in Active or Starting state. This article gives an example of a custom business rule that could add a timeout for Top-Down/Service Mapping type discoveries triggered by Change Requests, but could be used for other types of discovery status with a bit of modification. This article is not going to go into root cause for whatever is stuck or long running.CauseDiscovery status records, where description is "Discover CIs API" are triggered by updates to Change Request records, have no Discovery Schedule linked, so have no max runtime. If something has gone wrong, you may end up in a situation where the Discovery Status records remain active indefinitely, and need manually cancelling. ResolutionWhen a normal Scheduled Discovery runs, in addition to the scheduled job executing the discovery, an additional scheduled job called "Cancel Discovery" is created at the start of the schedule run. It is a run once job, set to run at the time the Max Runtime of the schedule is reached. You will see one of these these in the sys_trigger table for each scheduled discovery currently running. Each has a script to cancel the specific Discovery Status record of that discovery schedule. You can see the code that does this in the scheduleCancelJob and getCancelScript functions in the out-of-box "StartDiscovery" script include. A Business Rule, running on Insert of a Discovery Status record, could create a similar "Cancel Discovery" job. The attached update set contains: a Business rule "Add Cancel Schedule max runtime job", which runs on insert of a discovery_status, where the description is "Discover CIs API", and no schedule is linked. It simply has slightly modified versions of the scheduleCancelJob and getCancelScript functions in the out-of-box StartDiscovery script include. a Property "custom.discovery.timeout", which sets the seconds to allow the discovery job to run for. This is set to 7200 (= 2 hours), but could be changed. The business rule gets the duration from this property, instead of a discovery schedule. You can test this without needing a proper Change Request by: Temporarily set the custom.discovery.timeout property to a short value, e.g. 60Opening a blank Discovery Status form ( /discovery_status.do )Set description = Discover CIs APISave (remain on the form). You will see state is "Starting"Open another browser tab for a list of the Scheduler table ( /sys_trigger_list.do ) filter on name contains "Cancel Discovery". You should see a "Custom: Cancel Discovery" job just created, with a Next action corresponding to your timeout.Inspect the job, and confirm the discovery status name and sys_id is correct in the cancel script.Wait for the cancel job to run. At that point the sys_trigger record is automatically deleted, because it is a "run once" jobCheck the Discovery Status record is now cancelled. Notes: This should be considered an example, and is not supported codeThe condition in the Business rule could be changed to cover other kinds of Discovery Status as well or instead of.Related LinksAn Enhancement Request has been created in the Idea Portal, to have something like this added out-of-box. Please Upvote that idea if this would be useful, or don't like the idea of adding an unsupported customisation like this.