---
title: "Which Error is Most Common when Encountering Scheduled Scan Failures?"
url: "https://dm0bkdes5q7a2ls.productfruits.help/en/article/which-error-is-most-common-when-encountering-scheduled-scan-failures"
language: "en"
last_updated: "2026-06-01T14:24:30.105Z"
---

# Which Error is Most Common when Encountering Scheduled Scan Failures?

The most common "error" blocking scheduled scans is not actually a technical bug, but rather a Scope Design failure (often referred to as a "Blast Radius" issue).

While technical errors like "Access Denied" or "Connection Refused" are frequent, the following operational and configuration issues are the most common reasons a scan fails to run or complete as expected:

## 1\. Scope Design (The "Blast Radius" Failure)

The most frequent operational failure occurs when a scan is defined too broadly (for example, "Scan all 5,000 mailboxes for every possible data type").

This leads to:

-   **Throttling/Backoff:** Cloud targets (like M365 or Google Drive) block Agents if they request too much data too quickly.
-   **Extreme Runtimes:** The scan may still be "running" from the previous week, preventing the new scheduled instance from starting.
-   **Resource Exhaustion:** The Agent machine may run out of memory or CPU, causing the scan engine to crash silently.

## 2\. Permissions Mismatch (The Most Common Log Error)

Among actual log-level errors, **"Access Denied"** or **"Unauthorized"** is the most frequent.

-   This occurs when the service account used for the scan has had its permissions changed, its password expired, or its MFA requirements updated, preventing the Agent from enumerating the Target.

## 3\. Agent Connectivity (The "Heartbeat" Failure)

From a platform health perspective, the most common technical blocker is the **Agent being Offline**.

-   Because Agents run on customer-controlled endpoints or servers, they are frequently affected by:
-   -   Laptops being powered off or in sleep mode.
    -   VPNs being disconnected.
    -   Firewall rules being updated that block the Agent's outbound "heartbeat" to the console.

## 4\. Infrastructure Service Failures (v13.6 Specific)

In version 13.6, a common blocker is the **PostgreSQL or pgBouncer service not running** on the Agent host.

-   Since these services manage the job and shipper queues, if they are stopped (due to a reboot or resource conflict), the Agent cannot receive or process any scheduled work.

## Summary of "Most Common" by Category

| Category | Most Common Issue |
| --- | --- |
| **Operational** | **Unbounded Scope:** Scanning too much data at once. |
| **Technical (Log)** | **Access Denied:** Credential or permission failure. |
| **Infrastructure** | **Agent Offline:** Host is powered off or network is blocked. |
| **v13.6 Architecture** | **Service Down:** Local Postgres/pgBouncer is not running. |

## Pro-Tip for Troubleshooting

Always check the **Agent Health** in the console first.

If the Agent is "Red" or hasn't heartbeated in 10+ minutes, that is almost certainly why your scheduled scan didn't run.