Common Issues and Solutions

Resource Management Issues

Q: How do I resolve a "ghost" asset showing in Firefly? A: A ghost asset means Firefly sees a resource in IaC that no longer exists in cloud, or vice versa. To resolve:

If it's truly gone in cloud and you don't need it: Remove it from your IaC. For example, if Terraform still had a resource in state, use terraform state rm for that resource or delete it from code and run apply to update state. Firefly will then stop listing it as ghost since the IaC reference is gone.
If the resource exists in cloud but lost its IaC (or IaC was destroyed inadvertently): Decide if you want to reintroduce it to IaC or remove it entirely. You could codify it again (Firefly can generate a new Terraform file for it). Once managed, it's no longer ghost. Or you delete the resource from cloud (since maybe it was supposed to be destroyed when its IaC was removed, but wasn't).
Firefly has a feature to "Delete ghost assets' IaC file" – use this carefully: it means telling Firefly to stop tracking that asset as codified (essentially acknowledging it's unmanaged now). This might be fine for trivial resources, but ideally, you either remove the infra or recodify it rather than ignoring ghosts.
Preventing Ghosts: Use proper Terraform destroy commands rather than manual deletions. And use Terraform Cloud's drift detection or Firefly's governance to catch if someone manually deletes a resource they shouldn't. Ghosts are usually an indication of process break (someone deleted outside of IaC).

Q: Some of my cloud resources aren't recognized or shown as "unsupported" in Firefly. What does that mean? A: Firefly may show an indicator for resources it discovered but doesn't fully support (maybe an unfamiliar service). It might list them under Inventory with a note or simply skip some properties. Check the Support Matrix in Firefly docs to confirm. If unsupported:

Firefly will not evaluate policies on those or might not properly classify them as codified/unmanaged.
Typically, resources like new AWS services or very niche ones might not be parsed.
Solution: There isn't a direct fix on user side except to be aware. You can often manage those resources via IaC still, but Firefly might categorize them as "Managed (unsupported)" or something. Keep your IaC for them anyway.
Consider reaching out to Firefly support to request support for that resource type; they update the platform regularly to include more services.
In the meantime, ensure you manually govern those resources (maybe with native cloud tools or scripts) if they're critical, since Firefly might not catch violations on them.

Integration Issues

Q: I just integrated a cloud account, but I don't see any assets in Firefly. What should I do? A: First, ensure the integration was set up correctly:

Check the Integrations page for that account. Does it show as "Connected" or is there an error? If an error, click it to see details (e.g., wrong credentials or missing permissions).
Remember that for some providers, after integration, Firefly performs an initial full scan which can take some time if you have many resources. Give it a few minutes.
If using AWS and you did not enable event-driven mode, Firefly will rely on a periodic scan (once daily) to find assets. You can trigger a manual scan (for AWS, go to Settings > Integrations > the AWS account and click "Scan now" or the specific "Scan S3 for state files" or "Re-scan assets" button). The same concept applies to GCP/Azure if a manual scan option is present.
Verify the credentials: a common issue is that the IAM role or service account doesn't have all required read permissions. Check Firefly's Support Matrix or docs for required policies. E.g., if no assets are coming from AWS, ensure the IAM role has at least ReadOnlyAccess or equivalent custom policy attached. After updating permissions, re-run the scan.
If still empty, check Firefly's audit logs or contact support – there could be an uncommon edge case.

Q: Firefly shows "event-driven upgrade available" for my AWS integration. What is this? A: This means you integrated AWS in a polling mode and Firefly is suggesting to enable real-time updates. Event-driven uses AWS CloudTrail + SNS to push changes instantly. To upgrade:

Go to Integrations > AWS > Upgrade to Event-Driven (Firefly likely has a guide).
This usually involves deploying an additional CloudFormation stack or Terraform that sets up an SNS topic for CloudTrail and grants Firefly access.
Once done, Firefly will get events within seconds of changes. This drastically reduces drift detection time (from up to 24h down to minutes). It's recommended for production accounts especially. If you cannot for some reason (cost or complexity), know that Firefly will still scan daily to catch changes.

Notification and Alert Issues

Q: My Firefly notifications aren't coming through (Slack/Email/etc). How to debug? A:

First, verify in Firefly UI under Settings > Notifications that the rule is active (toggle on) and that events have indeed occurred that match it.
Check the destination integration: e.g., did you properly connect Slack? For Slack App, is Firefly app installed in the channel? For webhook, is the URL correct? Try a test: Firefly might have a "Send test message" button when setting up a notification integration.
Email: Check spam folder. The sender might be something like no-reply@firefly or similar. Ensure your email filters allow it.
PagerDuty: Make sure the integration key is correct and that the PD service is set to trigger on events from that integration.
If integration seems fine, consider the frequency: Firefly batches some notifications. For example, unmanaged detection might only notify once daily. You can test by creating a simple condition that you trigger (e.g., make a test resource violate a policy and see if a Slack message appears).
If nothing works, check Firefly's own alert log or contact support. There might be known issues or limitations (for instance, some users found Microsoft Teams webhooks require certain formatting – Firefly docs would note if any special steps needed).
Reconfigure if needed: sometimes deleting and re-adding the Slack/Email integration in Firefly resolves a glitch. Also ensure the Firefly API has permission for that action (Slack apps need scopes; Firefly's app likely requests chat:write which you must approve during install).

Policy and Guardrail Issues

Q: A Terraform plan is being blocked by a guardrail in Firefly, but I believe the change is okay. What can I do? A: This is by design – Firefly found something against policy. Options:

If you have override rights (the guardrail is Flexible), you can go into Firefly Workflows, find the run, and choose "Override" to proceed with apply (assuming you have rationale to do so). Make sure to document why in a comment or ticket, for traceability.
If the guardrail is Strict or you don't have override, you'll need to adjust the change to comply or get an admin to temporarily adjust the rule. For example, if policy says "No open ports" but you actually need to open port 80 (which might be acceptable), perhaps the policy is too broad and an admin can refine it (e.g., allow 80 but not 22). That requires policy update and re-run plan.
If it's a cost guardrail, maybe you truly need that bigger resource – in that case, coordinate with whoever manages guardrails to approve a one-time exception or raise the threshold.
Pro Tip: Firefly's guardrail message usually indicates which rule was violated. Use that info to quickly fix your code (e.g., add required tags, enable encryption, etc.) rather than fight the guardrail. It's there to help uphold standards.

PreviousJSON Output Example: Exporting Inventory NextFAQs

Last updated 1 month ago

Was this helpful?

Resource Management Issues

Q: How do I resolve a "ghost" asset showing in Firefly? A: A ghost asset means Firefly sees a resource in IaC that no longer exists in cloud, or vice versa. To resolve:

If it's truly gone in cloud and you don't need it: Remove it from your IaC. For example, if Terraform still had a resource in state, use terraform state rm for that resource or delete it from code and run apply to update state. Firefly will then stop listing it as ghost since the IaC reference is gone.

If the resource exists in cloud but lost its IaC (or IaC was destroyed inadvertently): Decide if you want to reintroduce it to IaC or remove it entirely. You could codify it again (Firefly can generate a new Terraform file for it). Once managed, it's no longer ghost. Or you delete the resource from cloud (since maybe it was supposed to be destroyed when its IaC was removed, but wasn't).

Firefly has a feature to "Delete ghost assets' IaC file" – use this carefully: it means telling Firefly to stop tracking that asset as codified (essentially acknowledging it's unmanaged now). This might be fine for trivial resources, but ideally, you either remove the infra or recodify it rather than ignoring ghosts.

Preventing Ghosts: Use proper Terraform destroy commands rather than manual deletions. And use Terraform Cloud's drift detection or Firefly's governance to catch if someone manually deletes a resource they shouldn't. Ghosts are usually an indication of process break (someone deleted outside of IaC).

Firefly will not evaluate policies on those or might not properly classify them as codified/unmanaged.

Typically, resources like new AWS services or very niche ones might not be parsed.

Solution: There isn't a direct fix on user side except to be aware. You can often manage those resources via IaC still, but Firefly might categorize them as "Managed (unsupported)" or something. Keep your IaC for them anyway.

Consider reaching out to Firefly support to request support for that resource type; they update the platform regularly to include more services.

In the meantime, ensure you manually govern those resources (maybe with native cloud tools or scripts) if they're critical, since Firefly might not catch violations on them.

Integration Issues

Q: I just integrated a cloud account, but I don't see any assets in Firefly. What should I do? A: First, ensure the integration was set up correctly:

Check the Integrations page for that account. Does it show as "Connected" or is there an error? If an error, click it to see details (e.g., wrong credentials or missing permissions).

Remember that for some providers, after integration, Firefly performs an initial full scan which can take some time if you have many resources. Give it a few minutes.

If using AWS and you did not enable event-driven mode, Firefly will rely on a periodic scan (once daily) to find assets. You can trigger a manual scan (for AWS, go to Settings > Integrations > the AWS account and click "Scan now" or the specific "Scan S3 for state files" or "Re-scan assets" button). The same concept applies to GCP/Azure if a manual scan option is present.

Verify the credentials: a common issue is that the IAM role or service account doesn't have all required read permissions. Check Firefly's Support Matrix or docs for required policies. E.g., if no assets are coming from AWS, ensure the IAM role has at least ReadOnlyAccess or equivalent custom policy attached. After updating permissions, re-run the scan.

If still empty, check Firefly's audit logs or contact support – there could be an uncommon edge case.

Go to Integrations > AWS > Upgrade to Event-Driven (Firefly likely has a guide).

This usually involves deploying an additional CloudFormation stack or Terraform that sets up an SNS topic for CloudTrail and grants Firefly access.

Once done, Firefly will get events within seconds of changes. This drastically reduces drift detection time (from up to 24h down to minutes). It's recommended for production accounts especially. If you cannot for some reason (cost or complexity), know that Firefly will still scan daily to catch changes.

Notification and Alert Issues

Q: My Firefly notifications aren't coming through (Slack/Email/etc). How to debug? A:

First, verify in Firefly UI under Settings > Notifications that the rule is active (toggle on) and that events have indeed occurred that match it.

Check the destination integration: e.g., did you properly connect Slack? For Slack App, is Firefly app installed in the channel? For webhook, is the URL correct? Try a test: Firefly might have a "Send test message" button when setting up a notification integration.

Email: Check spam folder. The sender might be something like no-reply@firefly or similar. Ensure your email filters allow it.

PagerDuty: Make sure the integration key is correct and that the PD service is set to trigger on events from that integration.

If integration seems fine, consider the frequency: Firefly batches some notifications. For example, unmanaged detection might only notify once daily. You can test by creating a simple condition that you trigger (e.g., make a test resource violate a policy and see if a Slack message appears).

If nothing works, check Firefly's own alert log or contact support. There might be known issues or limitations (for instance, some users found Microsoft Teams webhooks require certain formatting – Firefly docs would note if any special steps needed).

Reconfigure if needed: sometimes deleting and re-adding the Slack/Email integration in Firefly resolves a glitch. Also ensure the Firefly API has permission for that action (Slack apps need scopes; Firefly's app likely requests chat:write which you must approve during install).

Policy and Guardrail Issues

Q: A Terraform plan is being blocked by a guardrail in Firefly, but I believe the change is okay. What can I do? A: This is by design – Firefly found something against policy. Options:

If you have override rights (the guardrail is Flexible), you can go into Firefly Workflows, find the run, and choose "Override" to proceed with apply (assuming you have rationale to do so). Make sure to document why in a comment or ticket, for traceability.

If the guardrail is Strict or you don't have override, you'll need to adjust the change to comply or get an admin to temporarily adjust the rule. For example, if policy says "No open ports" but you actually need to open port 80 (which might be acceptable), perhaps the policy is too broad and an admin can refine it (e.g., allow 80 but not 22). That requires policy update and re-run plan.

If it's a cost guardrail, maybe you truly need that bigger resource – in that case, coordinate with whoever manages guardrails to approve a one-time exception or raise the threshold.

Pro Tip: Firefly's guardrail message usually indicates which rule was violated. Use that info to quickly fix your code (e.g., add required tags, enable encryption, etc.) rather than fight the guardrail. It's there to help uphold standards.