> 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/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/administration-and-troubleshooting/manage-instances/troubleshoot-errors-on-cloud-instances.md).
# Troubleshoot errors on cloud instances
To help you to troubleshoot errors on a cloud instance, Cortex XSIAM provides the following visibility and drilldown options:
* Overall status of an instance that indicates the health of your instance.
* A breakdown of the security capabilities enabled on an instance, detailing the status of each capability along with any open errors or issues.
* Additional XQL drill down options to query the history of error and recovery events for each security capability.
How to troubleshoot errors on a cloud instance
1. Navigate to **Settings** → **Data Sources & Integrations**.
Under **Cloud Service Provider**, review the status of the instances that were onboarded for the service provider. If the status shows **Warning** or **Error**, hover over the service provider and click **View Details**.
2. On the **Cloud Instances** page review the list of instances that were onboarded and their overall status. The status is displayed as follows:
* **Connected:** The connector is enabled and has no issues.
* **Warning:** The connector is enabled and has minor issues. For example, some accounts or capabilities are in warning or error status.
* **Error:** The connector is enabled and has substantial errors. For example, an authentication failure, an outpost failure, major permissions issues, or (for organization level accounts) the majority of the accounts in the instance are in error status.
* **Disabled:** The connector is disabled.
3. To understand why an instance is showing a **Warning** or **Error** status, click on the instance name.
The cloud instance panel provides a breakdown of the security capabilities and the accounts onboarded on the instance. Review the information in the following sections:
| Section | Context |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Header | Displays the overall status of the instance and the following information about the account, as specified during onboarding:
- Scope of the instance: The number of accounts onboarded on the instance and their status. See the Accounts section for more information about the individual accounts and the type of account (single account or organization).
- Scan mode: Cloud Scan or Outpost. For accounts using Outpost, information is displayed about the status of the Outpost account and the account ID.
- Resource Tags: Tags defined during onboarding.
|
| Security Capabilities | Displays a breakdown of the security capabilities enabled on the instance and their individual statuses. Click on any item that shows a warning or error status to see the open errors and issues that contributed to the status:
- Errors are factual objects that are automatically created when problems occur, and provide insight into the current status of the capability. For example, if a permission is missing, an error is displayed. Browse and filter the errors to better understand and resolve the problem.
Issues are actionable objects that are triggered when detected problems exceed defined thresholds. Issues are manageable, trackable, and provide remediation suggestions and automations.
The issues displayed in the panel are open issues that are specifically related to the selected connector with the selected capability in the observed scope (single account or organization). Click an issue to start investigating it.
|
| Accounts | Lists the accounts that are onboarded on the instance and their individual status.
If multiple accounts are onboarded on the instance, click on each account to filter the page information by account, and drill-down to the security capability statuses for each account.
|
4. If the instance shows an Outpost error, go to the **All Outposts** page and find the outpost account that is being used by this instance. Right click the Outpost account to view the open errors and issues for the account.
5. If the account shows **Permission** errors, use the side panel to check which permissions are missing. You can also **Edit** the instance to redeploy the cloud setup template, which should normally resolve the error.
6. Further investigate errors by running XQL queries on the `cloud_health_auditing` dataset.
This dataset records error and recovery events for the security capabilities in cloud instances. By querying this dataset you can see information about when the error started, the prevalence of the error, and whether there is a recurrency pattern. See the specific fields descriptions and query examples for each security capability.
Note
Errors related to collection of audit logs in the cloud instance are recorded in the collection_auditing dataset. For more information, see Audit logs fields and query examples.
Outpost fields and query examples
You can review Outpost entries in the `cloud_health_auditing` dataset to see Outpost activity over time, or to search for errors on specific accounts. Outpost entries are added to the dataset as follows:
* An error occurred on an Outpost account that disabled or prevented an operation. This is audited as **Error**.
* An exceptional condition occurred on an Outpost account that might cause problems if not resolved. This is audited as **Warning**.
* The Outpost account returns to normal function. This is audited as **Informational**.
The following table describes the fields for Outpost entries:
| Field | Description |
| -------------- | -------------------------------------------------------------------- |
| Account | Cloud account ID of the Outpost |
| Name | Category of the error, or a brief description of the event |
| Resource ID | Outpost ID |
| Capability | Outpost |
| Region | Region where the event occurred, or **All regions**. |
| Classification | Type of entry (Error, Warning, or Informational) |
| Message | Description of the error or **Connected** for informational entries. |
| Error | Details about the error. For informational entries this is blank. |
Examples of Outpost queries
* Identify Outpost errors on all Outpost accounts in the eu-west-3 region:
```programlisting
dataset = cloud_health_auditing | filter capability = "Outpost" and classification = "Error" and region = "eu-west-3"
```
* See all entries (error, warning, and recovery) for Outpost\_1 on cloud account Account\_A:
```programlisting
dataset = cloud_health_auditing | filter capability = "Outpost" and resource_id = “Outpost_1” and account = "Account_A"
```
Permissions fields and query examples
You can review Permissions entries in the `cloud_health_auditing` dataset to see Permissions activity over time, or to search for errors on specific accounts. Permissions entries are added to the dataset as follows:
* A permission problem was found. This is audited as **Error**.
* An exceptional condition occurred that might cause problems if not resolved. This is audited as **Warning**.
* A permission problem is resolved. This is audited as **Informational**.
The following table describes the fields for Permissions entries:
| Field | Description |
| -------------- | ------------------------------------------------------------------ |
| Account | Name of the account where the event occurred, or **All accounts**. |
| Connector | Name of the connector where the event occurred |
| Name | Permission name |
| Capability | Permissions |
| Classification | Type of entry (Error, Warning, or Informational) |
| Message | Description of the error or **Granted** for informational entries. |
Discovery engine fields and query examples
You can review Discovery engine entries in the `cloud_health_auditing` dataset to see Discovery activity over time, or to search for errors on specific accounts. Discovery entries are added to the dataset as follows:
* An API exec problem is found. This is audited as **Error**.
* An exceptional condition occurred that might cause problems if not resolved. This is audited as **Warning**.
* An API exec problem is resolved. This is audited as **Informational**.
The following table describes the fields for Discovery engine entries:
| Field | Description |
| -------------- | -------------------------------------------------------------------- |
| Account | Name of the account where the event occurred, or **All accounts** |
| Connector | Name of the connector where the event occurred |
| Name | Asset name |
| Capability | Discovery |
| Region | Region where the event occurred, or **All regions**. |
| Classification | Type of entry (Error, Warning, or Informational) |
| Message | Description of the error or **Connected** for informational entries. |
Examples of Discovery engine queries
* Identify API exec errors on the Discovery engine for all accounts on the AWS\_1 connector:
```programlisting
dataset = cloud_health_auditing | filter capability = "Discovery" and connector = "AWS_1" and classification = “Error”
```
* See all Discovery engine activity on connector AWS\_1 for Account\_ A in the af-south-1 region:
```programlisting
dataset = cloud_health_auditing | filter capability = "Discovery" and connector = "AWS_1" and account = "accountA" and region = "af-south-1"
```
Agentless Disk Scanning (ADS) fields and query examples
You can review ADS entries in the `cloud_health_auditing` dataset to see ADS activity over time, or to search for errors on specific accounts. ADS entries are added to the dataset as follows:
* ADS failed to scan an asset. This is audited as **Failed**.
* ADS successfully scanned an asset. This is audited as **Scanned**.
* The asset or host is not supported by ADS. This is audited as **Unsupported**.
* The asset or Host was excluded from the scan. This is audited as **Excluded**.
| Field | Description |
| -------------- | ----------------------------------------------------------------- |
| Account | Name of the account to which the asset belongs |
| Connector | ID of the connector |
| Name | Name of the asset |
| Resource ID | Asset ID |
| Capability | ADS |
| Region | Region where the asset is located |
| Classification | Type of entry (Failed, Unsupported, Excluded, Scanned) |
| Message | Description of the error, or Connected for informational entries. |
| Error | Details about the error. For informational entries this is blank. |
| Type | Type of asset that was scanned |
| Scope | Scope of the asset (Asset, Region, or Account) |
Examples of ADS queries
* Identify failed ADS scans on connector "a8df43e848dd42778ae7efd5a706a0fc" for EC2 assets at the asset scope level, filtered by region (northamerica-northeast2-a):
```programlisting
dataset = cloud_health_auditing | filter capability = "ADS" and classification = "failed" and connector = “a8df43e848dd42778ae7efd5a706a0fc” and type = "EC2_INSTANCE" and scope = "Asset" and region = "northamerica-northeast2-a"
```
* See all ADS scans (failed and successful) on connector "a8df43e848dd42778ae7efd5a706a0fc" for EC2 assets belonging to Account\_A:
```programlisting
dataset = cloud_health_auditing | filter capability = "ADS" and connector = “a8df43e848dd42778ae7efd5a706a0fc” and type = "EC2" and account = “Account_A”
```
Data Security Scanning (DSPM) fields and query examples
You can review DSPM entries in the `cloud_health_auditing` dataset to see DSPM activity over time, or to search for errors on specific accounts. DSPM entries are added to the dataset as follows:
* DSPM failed to scan an asset. This is audited as **Failed**.
* DSPM successfully scanned an asset. This is audited as **Success**.
The following table describes the fields for DSPM entries:
| Field | Description |
| -------------- | ----------------------------------------------------------------- |
| Account | Name of the account to which the asset belongs |
| Connector | Name of the connector where the event occurred |
| Name | Name of the asset |
| Resource ID | Asset ID |
| Capability | DSPM |
| Region | Region where the asset is located |
| Classification | Type of entry (Failed or Success) |
| Message | Description of the error, or Connected for informational entries. |
| Error | Details about the error. For informational entries this is blank. |
| Type | Type of asset that was scanned |
| Scope | Scope of the asset (Asset, Region, or Account) |
Examples of DSPM queries
* Identify failed DSPM scans on the AWS\_1 connector for S3 asset types, filtered by region (ap-east-1):
```programlisting
dataset = cloud_health_auditing | filter capability = "DSPM" and classification = “Error” and connector = “AWS_1” and type = "S3_BUCKET" and region = "ap-east-1"
```
* See all DSPM scans (failed and successful) on the AWS\_1 connector, for all scanned assets on Account\_A:
```programlisting
dataset = cloud_health_auditing | filter capability = "DSPM" and account = "Account_A" and connector = “AWS_1”
```
Registry scanning fields and query examples
You can review Registry scanning entries in the `cloud_health_auditing` dataset to see Registry scanning activity over time, or to search for errors on specific accounts. Registry scanning entries are added to the dataset as follows:
* The Registry scanner failed to scan an asset. This is audited as **Failed**.
* The Registry scanner successfully scanned an asset. This is audited as **Scanned**.
The following table describes the fields for Registry scanning entries:
| Field | Description |
| -------------- | ---------------------------------------------------------------- |
| Account | Name of the account to which the asset belongs |
| Connector | Name of the connector where the event occurred |
| Resource ID | Asset ID |
| Capability | Registry |
| Classification | Type of entry (Scanned or Failed) |
| Error | Details about the error. For informational entries this is blank |
| Scope | Scope of the asset (Asset or Account) |
Examples of Registry scanning queries
* Identify failed scans on connector GCP\_1:
```programlisting
dataset = cloud_health_auditing | filter capability = "Registry" and classification = “error” and connector = “GCP_1”
```
* Review all registry scans (failed and successful) on connector GCP\_1 for asset Asset\_A:
```programlisting
dataset = cloud_health_auditing | filter capability = "Registry" and connector = “GCP_1” and ressource_id = "Asset_A"
```
Audit logs fields and query example
You can review Audit logs entries in the `collection_auditing` dataset. Querying this dataset can help you see the connectivity changes of an instance over time, the escalation or recovery of the connectivity status, and the error, warning, and informational messages related to status changes. For more information about this dataset, see [Verify collector connectivity](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/administration-and-troubleshooting/verify-collector-connectivity.md).
The following table describes the fields for Audit logs entries:
| Field | Description |
| -------------- | --------------------------------------------------------------------- |
| Instance | Instance name |
| Log type | Type of logs affected |
| Classification | Type of entry (Error, Warning, or Informational) |
| Collector type | Type of the collector |
| Description | Description of the error, or **Connected** for informational entries. |
Audit logs query example
Identify disruptions (errors) in audit log collection on connector AWS\_1:
```programlisting
dataset = collection_auditing | filter instance = “AWS_1” and log_type = "Audit Logs" and classification = “Error”
```
Correlation rule examples
The following examples show how to set up correlation rules to trigger Health Collection issues when errors occur on a specific security capability.
Example rule for DSPM errors
In this example, a correlation rule will trigger a Health Collection issue if a DSPM scan fails on an AWS\_S3 asset on the AWS\_1 connector.
Example XQL:
```programlisting
dataset = cloud_health_auditing | filter capability = "DSPM" and classification = “Error” and type = "AWS_S3" and scope = "Asset" and connector = “AWS_1”
```
Additional fields to specify in the correlation rule:
| Field | Value |
| ----------------- | ------------------------------------ |
| Time Schedule | Hourly |
| Query time frame | 1 Hour |
| Issue Suppression | Select **Enable issue suppression**. |
| Action | Select **Generate Issue**. |
| Issue Domain | Health |
| Severity | Medium |
| Category | Collection |
Example rule for Outpost errors
In this example, a correlation rule will trigger a Health Collection issue if an error is recorded on account Outpost\_A in the us-east-1 region.
Example XQL:
```programlisting
dataset = cloud_health_auditing | filter capability = "Outpost" and account = "Outpost_A" and region = "eu-west-3" and classification = "Error"
```
Additional fields to specify in the correlation rule:
| Field | Value |
| ----------------- | ------------------------------------ |
| Time Schedule | Hourly |
| Query time frame | 1 Hour |
| Issue Suppression | Select **Enable issue suppression**. |
| Action | Select **Generate Issue**. |
| Issue Domain | Health |
| Severity | Medium |
| Category | Collection |
---
# 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/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/administration-and-troubleshooting/manage-instances/troubleshoot-errors-on-cloud-instances.md?ask=&goal=
```
`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.