Hi @Fariya Muskhan ,
The Scan Engine Properties and the protected Scheduled Script Executions serve different purposes.
The Scan Engine Properties define when and how a scan is eligible to run. The protected Scheduled Script Executions provide the background processing that checks for eligible scan work and processes the scan queue.
The 15-minute interval does not normally mean that a complete instance scan runs every 15 minutes.
Supported execution model:
Scan Engine Properties
-> Define schedule and scanning behavior
-> Protected scheduled job checks for eligible work
-> Scan request is created or queued
-> Scan Engine processes the scan in batches
-> Findings are reconciled
-> Scan status and summary records are updated
1. How are the properties and scheduled jobs linked?
The Scan Engine Properties are passive configuration. They do not execute code themselves.
The ServiceNow scheduler runs the protected Scan Engine jobs. Those jobs use the Scan Engine configuration to determine whether work should be initiated or processed.
Because the jobs and supporting Script Includes are protected, their internal implementation should be treated as product internals. Do not modify, clone, disable, or invoke them directly.
2. Which component initiates the scan?
Technically, the ServiceNow scheduler executes the Scheduled Script Execution.
The scheduled job then evaluates or processes Scan Engine work according to the configured Scan Engine Properties.
Therefore:
Scan Engine Property
-> Defines the required schedule
Scheduled Script Execution
-> Performs the background evaluation and processing
The property itself does not initiate a scan.
3. Why does the job run every 15 minutes when the scan is scheduled for 2:00 AM?
The 15-minute schedule is a polling or worker interval.
For example, when the configured scan time is 2:00 AM, the background job may run repeatedly but should initiate scheduled scan work only when the configured time is due and the other eligibility checks are satisfied.
The actual start may occur on the first eligible worker cycle at or after the configured time rather than exactly at 2:00:00 AM.
The worker may also be responsible for activities such as:
- Detecting queued scan requests
- Preventing overlapping scans
- Starting eligible batches
- Continuing scan processing
- Updating progress
- Reconciling findings
- Recovering or recalculating scan state
Do not change the protected job interval to match the daily scan time. The daily schedule should be managed through Scan Engine Properties.
4. How is Full Scan versus Delta Scan determined?
The documented behavior is:
- The first instance scan establishes the baseline and is a Full Instance Scan.
- Subsequent eligible instance scans normally use Delta Scan processing.
- Delta scans evaluate records changed since the previous scan.
- The Scan Engine can use modified application files and sys_update_xml information to identify relevant changes.
- Force Full Scan can be used when a complete rescan is required.
- A definition with Delta Scans Not Applicable enabled is evaluated as a full scan even during delta processing.
The final scan type should be verified on the Summary Scan record rather than inferred from the name of the protected Scheduled Script Execution.
A protected job named Scan Engine Full Scan should not automatically be interpreted as running a full instance scan every 15 minutes.
5. Which records track scan execution?
The supported records to review are:
Current scan execution:
Impact > Platform Health > Scan Status
Table:
sn_se_scan_status
This shows information such as:
- Scan type
- Current status
- Percentage complete
- Current processing step
- Batches
- Messages
- Status history
Completed scan history:
Impact > Platform Health > Summary Scans
Table:
sn_se_summary_scan
This records the completed scan, including its type, status, timing, and related findings.
Findings:
Impact > Platform Health > Open Findings
You can also review the Findings related list from the Summary Scan record.
The publicly available documentation does not describe a supported internal checkpoint table or every protected field used to calculate the delta boundary. Therefore, I would not build custom logic against undocumented Scan Engine backend records.
Recommended troubleshooting:
1. Confirm Activate Scan Engine is enabled.
2. Confirm Run Scheduled Scan is enabled.
3. Verify the configured time zone and time.
4. Review sn_se_scan_status around the scheduled time.
5. Review sn_se_summary_scan and confirm the actual scan type.
6. Check the scan status Messages and Status history.
7. Confirm that another instance scan was not already running.
8. Review the Impact and Scan Engine Store application versions.
9. Do not modify the protected Scheduled Script Executions.
10. Open a Now Support case if the scheduled time is reached but no scan request or status record is created.
Official references:
Configure Scan Engine properties:
https://www.servicenow.com/docs/r/impact/configure-scan-engine-properties.html
Scan Engine overview:
https://www.servicenow.com/docs/r/zurich/impact/impact-scan-engine-overview.html
Full and Delta instance scans:
https://www.servicenow.com/docs/r/impact/scan-engine-parallel-processing.html
View Scan Engine results:
https://www.servicenow.com/docs/r/impact/viewing-scan-results-scan-engine.html
Create and configure Scan Engine definitions:
https://www.servicenow.com/docs/r/impact/create-scan-engine-definitions.html
In summary, the 2:00 AM setting is the business schedule, while the 15-minute protected job is part of the background polling or processing mechanism. The property determines when the scan is due; the scheduled backend process performs the execution.
Hope this helps!
If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.
Kind Regards,
Abhishek Pal
