Sometimes a scan finishes successfully but could not read every data source. Parsivex records these as partial scan warnings — yellow alerts on your report and scan results page titled Partial scan — some data was unavailable.
Partial scans are not failures. They mean Parsivex finished the scan with gaps in coverage. Findings for accessible resources are still generated and saved.
Why partial scans happen
Partial warnings appear when a non-fatal error occurs during data collection:
| Cause | What happens |
|---|---|
| Permission gaps | The IAM role can be assumed, but specific API calls return access denied (Cost Explorer, DynamoDB, ELB, etc.) |
| Cost Explorer not enabled | AWS Cost Explorer has not been activated on the account yet |
| API throttling | Rare for inventory services; required services that hit rate limits can fail the scan instead of warning |
| Per-resource errors | A single S3 bucket or resource returns an error; that resource is skipped while the rest of the scan continues |
Parsivex is designed so that one missing permission or one unreachable resource does not block findings for everything else.
Warning labels you may see
The app shows clear messages for each issue. Here are the warnings Parsivex can surface, matching the labels shown in your report:
Cost Explorer not enabled
Label shown:
AWS Cost Explorer is not yet enabled on this account. It can take up to 24 hours after your first AWS visit before cost data becomes available. Cost-based findings (e.g. NAT Gateway overuse, Reserved Instance opportunities) were skipped. Re-run the scan once Cost Explorer is active.
What to do: Open the AWS Billing console and enable Cost Explorer. Wait up to 24 hours for AWS to activate it, then run a new scan.
Cost Explorer access denied
Label shown:
Access was denied to AWS Cost Explorer. Check that the Parsivex IAM role has the ce:GetCostAndUsage permission. Cost-based findings were skipped.
What to do: Attach the full Parsivex read-only policy from /security or redeploy the CloudFormation/Terraform template. See Connection troubleshooting → Missing permissions during verify or scan.
DynamoDB access denied
Label shown:
Access was denied to DynamoDB. Re-deploy the Parsivex CloudFormation stack or add dynamodb:ListTables and dynamodb:DescribeTable to your IAM role. DynamoDB findings were skipped.
What to do: Update your IAM policy with DynamoDB read permissions. The IaC templates include these statements — see Deploy with CloudFormation or Terraform.
Elastic Load Balancing access denied
Label shown:
Access was denied to Elastic Load Balancing. Re-deploy the Parsivex CloudFormation stack or add elasticloadbalancing:Describe* to your IAM role. Load balancer findings were skipped.
What to do: Add ELB describe permissions to your role. Compare your policy against /security.
ElastiCache access denied
Label shown:
Access was denied to ElastiCache. Re-deploy the Parsivex CloudFormation stack or add elasticache:Describe* to your IAM role. ElastiCache findings were skipped.
What to do: Add ElastiCache describe permissions to your role. Compare your policy against /security.
Redshift access denied
Label shown:
Access was denied to Redshift. Re-deploy the Parsivex CloudFormation stack or add redshift:Describe* to your IAM role. Redshift findings were skipped.
What to do: Add Redshift describe permissions to your role. Compare your policy against /security.
Redshift not enabled
Label shown:
Redshift is not enabled for this AWS account. Redshift findings were skipped.
What to do: No action required if you do not use Redshift. This warning appears when AWS has not activated Redshift for your account — it is not an IAM misconfiguration. The rest of your scan still completes normally.
EFS access denied
Label shown:
Access was denied to EFS. Re-deploy the Parsivex CloudFormation stack or add elasticfilesystem:Describe* to your IAM role. EFS findings were skipped.
What to do: Add EFS describe permissions to your role. Compare your policy against /security.
CloudWatch Logs access denied
Label shown:
Access was denied to CloudWatch Logs. Re-deploy the Parsivex CloudFormation stack or add logs:Describe* and logs:List* to your IAM role. CloudWatch Logs findings were skipped.
What to do: Add CloudWatch Logs read permissions to your role. Compare your policy against /security.
Other service access denied (inventory)
Label shown:
Access was denied to . Related findings were skipped.
This generic message appears when an optional inventory source returns access denied. DynamoDB, ELB, ElastiCache, Redshift, EFS, and CloudWatch Logs have more specific messages above; other services use this fallback.
What to do: Review Connection troubleshooting and ensure your role matches the Parsivex minimal policy.
Other Cost Explorer errors
If Cost Explorer fails for another reason, Parsivex shows the underlying error message. Common causes include temporary credentials expiring mid-scan (retry the scan) or an unexpected AWS API error (retry; contact support if it persists).
Partial scans still produce findings
When you see partial scan warnings:
- Findings for accessible resources are included in your report with full savings estimates
- Skipped checks simply do not appear — for example, no NAT Gateway finding if Cost Explorer was unavailable
- Parsivex does not mark findings as resolved for categories that were skipped during the scan (for example, ElastiCache findings when ElastiCache inventory was unavailable)
- Your scan counts as complete — it shows as Completed, not Failed
- Findings in fully scanned categories can still be marked resolved on partial scans when their data sources were available — for example, an idle EC2 instance you terminated is still verified even if Cost Explorer failed on the same scan
- Cost-based findings are not marked resolved when Cost Explorer was unavailable on this scan — Parsivex cannot verify that NAT Gateway or Reserved Instance waste is gone without billing data, so those findings stay open until a scan with Cost Explorer succeeds
Re-run the scan after fixing permissions or enabling Cost Explorer to fill in the gaps.
Partial scans vs failed scans
| Partial scan (warnings) | Failed scan | |
|---|---|---|
| Status | Completed (with warnings) | Failed |
| Report | Generated with available findings | Not generated |
| Warnings | Yellow partial-scan alerts | Error message on scan page |
| Previous findings | Unchanged unless new scan resolves them (only for fully scanned categories) | Not resolved — failed scans never trigger resolution |
| Typical cause | Missing optional permission or Cost Explorer not enabled | Required inventory step failed (e.g. EC2 or RDS list denied) |
Parsivex marks findings as resolved only after scans that complete successfully and fully scanned the affected category. If a scan fails entirely, Parsivex does not mark any open findings as resolved. If a scan completes with partial warnings (for example, ElastiCache inventory was skipped), findings in those skipped categories are not marked resolved — even if they disappear from the report — because Parsivex could not verify your account state. Findings in categories that were fully scanned can still be resolved normally. See Finding lifecycle for the full rules.
How to fix permission-related warnings
- Compare your IAM role policy to the policy on /security
- Walk through Connection troubleshooting — especially Missing permissions during verify or scan and Partial scan warnings due to permission gaps
- If you deployed with IaC, redeploy or update the stack so new permission statements take effect — see IaC setup
- Run a new scan to confirm warnings are gone
Related articles
- How scans work — Full scan process and data sources
- Connection troubleshooting — Fix IAM and trust policy issues
- Set up a read-only IAM role — Create or verify your Parsivex role
- Finding lifecycle — How dismiss, snooze, and resolve work