> For the complete documentation index, see [llms.txt](https://docs.debricked.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.debricked.com/product/automation/monitoring.md).
# Monitoring
OpenText Core SCA automation policies normally trigger based on pipeline events, such as committing a code to a repository. When the source code is committed, a OpenText Core SCA scan starts and automations run. However, in some cases, you might want to use automations to check the status of a repository even if you have not made any changes to it. For example, new vulnerabilities might be discovered for dependencies in repositories that are not updated regularly. Monitoring allows you to get timely warnings about issues in such repositories by automatically and periodically checking the rules regardless of pipeline events. It is possible to configure monitored automations to either result in webhooks or emails when triggered.
To enable monitoring for a new rule, follow these steps:
1. From a repository page, go to the **Automations** tab. On the Automations page, you can view the list of automation rules created.
2. On the Automations page, click **New** -> **Add rule**. The Add a new rule page is displayed.
3. On the Add a new rule page, select the valid vulnerability or malware condition from the drop-down. The vulnerability condition must be either 'CVSS' or 'discovery date' or "vulnerability is exploited". The malware condition must be "dependency is malicious".
4. Select the valid trigger events from the drop-down. The trigger events must be either 'notify by email', 'notify user groups by email' or 'trigger webhook'.
5. Click **Enable monitoring** check box to enable the monitoring for the rule.
6. Click **Generate rule** and review any warnings (if applicable).
7. Click **Save**.
{% hint style="info" %}
When the monitoring is enabled for a rule, on the Automations page, you can view the  icon next to the rule.
{% endhint %}
To enable monitoring for an existing rule, follow these steps:
1. From a repository page, go to the **Automations** tab. On the Automations page, you can view the list of automation rules created.
2. Click the **… (three dots)** on the right-hand side of the rule.
3. Select **Edit rule.**
4. On the Edit rule page, select the valid vulnerability or malware condition from the drop-down. The vulnerability condition must be either 'CVSS' or 'discovery date' or "vulnerability is exploited". The malware condition must be "dependency is malicious".
5. Select the valid trigger events from the drop-down. The trigger events must be either 'notify by email', 'notify user groups by email' or 'trigger webhook'.
6. Click **Enable monitoring** check box to enable the monitoring for the rule.
7. Click **Generate rule** and review any warnings (if applicable).
8. Click **Save**.
To filter the rules, follow these steps:
1. From a repository page, go to the **Automations** tab. On the Automations page, you can view the list of automation rules created.
2. On the Automations page, click **filter**. The Filter by page is displayed.
3. On the Filter by page, select the appropriate values to filter the rules. You can filter the rules based on:
* Activation: The values are 'Active' and 'Inactive'.
* Action: The values are 'Fail pipeline', 'Pipeline warning', 'Notify by email', 'Mark as unaffected', 'Flag as vulnerable' and 'Trigger webhook'.
* Monitoring: The values are 'Enabled' and 'Disabled'.
* Default rules: The values are 'Default rules' and 'Non default rules'.
---
# 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://docs.debricked.com/product/automation/monitoring.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.