mirror of
https://github.com/prowler-cloud/prowler.git
synced 2026-06-10 13:32:44 +00:00
147 lines
6.8 KiB
Plaintext
147 lines
6.8 KiB
Plaintext
---
|
|
title: 'Alerts'
|
|
description: 'Create email alerts from Prowler Cloud findings to monitor relevant security changes after scans or in daily digests.'
|
|
---
|
|
|
|
import { VersionBadge } from "/snippets/version-badge.mdx"
|
|
|
|
<VersionBadge version="5.26.0" />
|
|
|
|
Alerts notify recipients by email when security findings match saved filter conditions. Use Alerts to track high-priority findings, monitor specific providers or services, and keep teams informed about scan results that match defined criteria.
|
|
|
|
<Note>
|
|
This feature is available exclusively in **Prowler Cloud** and **Prowler Enterprise** with a [paid subscription](https://prowler.com/pricing).
|
|
</Note>
|
|
|
|
## Prerequisites
|
|
|
|
Before creating Alerts, ensure that:
|
|
|
|
* At least one scan has completed and produced findings.
|
|
* The user role includes the `manage_alerts` permission.
|
|
|
|
The `manage_alerts` permission is required to create, edit, test, enable, disable, and delete Alerts. See [RBAC Administrative Permissions](/user-guide/tutorials/prowler-app-rbac#rbac-administrative-permissions) for details.
|
|
|
|
## How Alerts Work
|
|
|
|
Alerts are created from Findings filters. When an Alert runs, Prowler Cloud evaluates the saved conditions against findings and sends an email digest when matching findings exist.
|
|
|
|
<Note>
|
|
Alerts evaluate findings with status `FAIL` only. Findings with status `PASS` or `MANUAL`, and muted findings, never trigger an Alert regardless of the saved filters.
|
|
</Note>
|
|
|
|
Alerts run on one of three schedules:
|
|
|
|
| Frequency | Description |
|
|
|-----------|-------------|
|
|
| After each scan | Evaluates the Alert after each completed scan. |
|
|
| Daily digest | Evaluates the Alert once per day and sends a digest when findings match. |
|
|
| After each scan and daily | Evaluates the Alert after every scan and in the daily digest. |
|
|
|
|
## Creating an Alert From Findings
|
|
|
|
To create an Alert:
|
|
|
|
1. Navigate to **Findings** in Prowler Cloud.
|
|
2. Apply at least one [Alert-compatible filter](#alert-compatible-filters) to define the findings that should trigger the Alert.
|
|
3. Click **Create Alert**.
|
|
|
|

|
|
|
|
4. Configure the Alert settings:
|
|
* **Name:** Add a short, descriptive name.
|
|
* **Description:** Add optional context for the Alert.
|
|
* **Frequency:** Select when Prowler Cloud should evaluate the Alert.
|
|
* **Recipients:** Select the recipients who should receive the email digest.
|
|
|
|

|
|
|
|
5. Click **Create**.
|
|
|
|
After the Alert is created, Prowler Cloud evaluates it based on the selected frequency.
|
|
|
|
## Alert-Compatible Filters
|
|
|
|
An **Alert-compatible filter** is a Findings-page filter that the Alert condition language can evaluate when the Alert runs. The Findings page exposes many filters, but only a specific subset can be saved into an Alert. Filters outside this subset, such as **Status**, free-text search, sort, or pagination, are ignored when seeding an Alert from the current Findings view.
|
|
|
|
When **Create Alert** is clicked on the Findings page, Prowler Cloud takes the active filters, keeps only the Alert-compatible ones, and uses them to build the Alert condition.
|
|
|
|
The following filters are Alert-compatible:
|
|
|
|
* Provider type
|
|
* Provider
|
|
* Severity
|
|
* Delta (new findings since the previous scan)
|
|
* Region
|
|
* Service
|
|
* Resource type
|
|
* Category
|
|
* Resource group
|
|
|
|
If only the **Status** filter is applied on the Findings page, Prowler Cloud substitutes all severities as the condition base so the Alert can still be created. Status itself never becomes part of the Alert condition.
|
|
|
|
## Managing Alerts
|
|
|
|
Navigate to **Alerts** to review and manage existing Alerts.
|
|
|
|

|
|
|
|
Each Alert provides these actions:
|
|
|
|
| Action | Description |
|
|
|--------|-------------|
|
|
| Edit | Update name, description, recipients, frequency, or filters. |
|
|
| Enable/Disable | Start or stop Alert evaluation without deleting the Alert. |
|
|
| Delete | Permanently remove the Alert. |
|
|
|
|
## Testing Alert Filters
|
|
|
|
When editing an Alert, click **Test** to preview whether the current filters match existing findings.
|
|
|
|
The test result indicates whether the filters match findings and includes a summary of the matching results.
|
|
|
|

|
|
|
|
<Warning>
|
|
**The Test result is a snapshot, not a guarantee of future Alert triggers.**
|
|
|
|
The Test evaluates the current filters against existing findings at the moment **Test** is clicked. It does not predict whether the Alert will trigger on its next evaluation. The Alert trigger depends on the state at evaluation time:
|
|
|
|
* **After each scan:** The Alert is evaluated against the findings produced by that scan only. If the next scan produces no findings that match the filters, the Alert will not trigger, even if a Test run earlier in the day showed matches.
|
|
* **Daily digest:** The Alert is evaluated against the findings present on the digest day. If no matching findings exist for that day, the Alert will not trigger, even if previous days had matches.
|
|
|
|
The reverse is also true: a Test showing no matches does not guarantee the Alert will stay silent. Future scans may produce matching findings.
|
|
|
|
Use **Test** to validate that the filters are well-formed and target the intended findings, not to forecast future Alert behavior.
|
|
</Warning>
|
|
|
|
## Recipients
|
|
|
|
Alert recipients are selected from the email addresses available in the tenant. Recipients receive an email digest each time an Alert evaluates and matches findings.
|
|
|
|
<Note>
|
|
By default, the **organization owner** receives a **daily digest** for **critical findings**. Adjust the recipient, frequency, or filters in the Alert configuration to change this behavior.
|
|
</Note>
|
|
|
|
If a recipient unsubscribes from Alerts, that address stops receiving digests until it is reconfirmed.
|
|
|
|
## Email Notifications
|
|
|
|
When an Alert matches findings, Prowler Cloud sends a security alert email that summarizes the matching findings. The email includes:
|
|
|
|
* The scan name and evaluation time.
|
|
* The total number of matching findings.
|
|
* The number of Alert rules that triggered.
|
|
* A preview of the affected findings, grouped by severity, with resource details and the originating rule.
|
|
* A direct link to view all matching findings in Prowler Cloud.
|
|
|
|

|
|
|
|
## Best Practices
|
|
|
|
* **Start with focused filters:** Create Alerts for specific high-priority scopes, such as critical findings, production providers, or important services.
|
|
* **Use clear names:** Choose names that explain the intent of the Alert.
|
|
* **Review recipients regularly:** Keep recipient lists aligned with current ownership.
|
|
* **Test before saving edits:** Use **Test** after changing filters to confirm that the Alert matches the expected findings.
|
|
* **Disable instead of deleting during tuning:** Disable Alerts temporarily when adjusting filters or recipients.
|