Why Would a Scheduled Scan Fail to Run on its Scheduled Day and Time?

Based on the platform's architecture and common operational "gotchas," here are the most likely causes of scheduled scans failing to run:

1. Agent Connectivity and Health

The most common reason is that the Search Agent responsible for the work is unavailable.

• Offline Status: If the Agent is powered off, disconnected from the network, or behind a firewall/VPN that it cannot traverse, it cannot receive the "work request" from the console.
• Service Failures: The core Agent services (like the Endpoint Service or SystemSearch service) may have stopped running on the host machine.
• Registration Issues: If the Agent has lost its trust relationship (registration) with the console, it stops heartbeating and cannot accept new jobs.

2. Resource and Queue Conflicts

• Overlapping Scans: If a previous scan is still running on the same Agent, the new scheduled scan may be queued or blocked depending on the Agent's configuration.
• Postgres Queue Issues: For Windows Agents, if the local PostgreSQL database (which manages the job_queue) is corrupted or the service is stopped, the Agent cannot process new units of work.
• Throttling: If the Target (for example, Exchange Online or a cloud storage provider) is heavily throttling the Agent due to previous high-volume activity, the scan may fail to initialize.

3. Authentication and Permissions

• Expired Credentials: If the service account or OAuth token used to authenticate to the Target has expired or been revoked, the scan fails immediately upon starting.
• Permission Changes: If the Agent's local permissions or the service account's access to the data source has changed, the scan may be unable to enumerate the Target.

4. Configuration and Scope "Gotchas"

• Empty Scope: If the scan is scoped using Agent Tags or Target Tags, and those tags have been removed or no longer match any active infrastructure, the scan has "nowhere to look" and may not trigger.
• Maintenance Windows: If a scan is scheduled to run during a window that has since been restricted by a global policy or blackout period, it is suppressed.
• Timezone Mismatch: Ensure the schedule is set relative to the correct timezone (Console time vs. Agent local time).

5. Console/Platform Issues

• Scan Definition vs. Run: Ensure the Scan Definition is actually "Enabled." A disabled definition will not trigger its associated schedule.
• License Expiration: If the platform license has expired or a specific module (like a database connector) is no longer licensed, the associated scans will not run.

Troubleshooting

Use the following high-level steps to troubleshoot scans that fail to run on schedule.

1. Check Agent Health: Go to the Agents page and verify the Agent is "Online" and heartbeating.
2. Review Job History: Look at the Jobs or Recent Activity page to see if the scan attempted to start and failed with an error code.
3. Inspect Agent Logs: On the host machine, check the EPS and IDF/SystemSearch logs for "Access Denied" or "Connection Refused" messages at the scheduled start time.