> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/branch-periodic-scans/branch-periodic-scan-workflow/diagnose-a-scan-failure-through-data-source-instance-health.md).

# Diagnose a scan failure through data source instance health

Scan failures originate in the connection between Cortex Cloud and the version control system. The data source instance health view reports the specific cause per repository, which the scan inventory does not.

1. Navigate to **Settings** → **Data Sources & Integrations**.
2. Filter for the data source, such as GitHub (SaaS). The data source displays the number of connected instances and the status of each instance. Status values are **Connected**, **Error**, **Warning**, and **Disabled**.
3. Select the data source. A list of data source instances is displayed.
4. Select the instance. The instance opens and reports the status of the instance alongside the **Review health** control, together with the connected repositories and the instance type, such as cloud. Read the status here before opening the health view — the status is a property of the instance, and the health view explains the status rather than reporting it.
5. Select **Review health**. The health status page opens and displays a list of repositories connected to the instance, including the status, the scan coverage (the connected scanners such as SCA, Secrets, and IaC, and the scan status), the location (scanned branch, organization, repository), and the timestamp.
6. Review instance-level issues. Select **Review Health** in the top bar to display the errors by repository and the errors related to the instance. Each entry reports:

* **Classification:** **Warning** or **Error**
* **Error Type:** **Permission**, **Clone**, **Connection**, **Webhook subscription**, or **Token**
* **Repository:** The repository containing the issue

7. Review repository-level issues. Select a repository in the table with a status of **Error** or **Warning** to display the repository-related warnings and errors, including the description, the type, the location, and the timestamp.
8. Correct the cause identified by the **Error Type** value. See [Reference E: Instance health error types](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/branch-periodic-scans/references/reference-e-instance-health-error-types.md).

**Result:** The scan failure is attributed to a specific, correctable cause. Return to [Triage a scan that failed or completed partially](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/branch-periodic-scans/branch-periodic-scan-workflow/triage-a-scan-that-failed-or-completed-partially.md) and trigger the rescan once the cause is corrected.

> **Note:** Instance status aggregates repository status. An instance reports **Error** when more than 50 percent of the associated repositories have errors, when a token error exists for a repository, when permissions are missing at error severity, when a webhook subscription error occurs at error severity, or when at least one repository includes a warning. An instance reports **Warning** when fewer than 50 percent of the associated repositories have errors, when permissions are missing at warning severity, or when a webhook subscription error occurs at warning severity.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/branch-periodic-scans/branch-periodic-scan-workflow/diagnose-a-scan-failure-through-data-source-instance-health.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.