Alert correlation groups related alerts into an inference so responders can work from one correlated context instead of many independent alerts. The new policy UI lets you control when alerts are eligible, how they are grouped over time, and what similarity conditions must match.
Key outcomes of a well-configured policy:
- Lower alert volume through grouped inferences.
- Better root-cause investigation context.
- Faster incident triage.
Access and purpose
Use this policy when you want to reduce alert noise and tie related alerts to a common incident timeline.
Go to Setup > Account > Alert Policies. Select Alert Correlation and click Create New or + Add.
Permissions typically required:
- OpsQ View and OpsQ Manage to access policy configuration.
- Administrative role scope (partner/client) based on tenancy model.
Policy states
Choose one state at the top of the form:
- Enabled: The policy is active and correlations are applied.
- Observed: The policy runs in observation mode so you can evaluate behavior before full activation.
- Disabled: The policy is saved but not applied.
Practical rollout pattern:
- Start in Observed mode.
- Review resulting inferences and correlated alerts.
- Move to Enabled after validation.
General details
| Field | Description |
|---|---|
| Policy Name | Required. Use a descriptive name that reflects scope and logic, for example: Network Tunnel Correlation - 15m. |
Policy filter
Use filters to restrict which alerts are evaluated by this policy.
| Field | Description |
|---|---|
| Resource Filter | Optional selector. Use this when correlation should apply only to selected resources or resource groups. Click the edit icon to open Resource Filter Criteria. |
| Filter Criteria | Optional query builder. Click + Query to add one or more conditions such as resource type, metric, site, or custom attributes. |
When you open Resource Filter Criteria, the dialog shows a query area and a result grid with these columns: Name, IP Address, OS, and Resource Type. The Apply button stays disabled until a query is built.
Use filter criteria only when needed. Over-filtering can prevent related alerts from being correlated.
Note: Correlation is typically site-aware, so alerts from different sites are usually not grouped together.
Policy rules
| Field | Description |
|---|---|
| Inference Subject | Defines how the inference subject is populated. If empty, the first matched alert subject is used. |
| Inference Criteria | Optional query criteria used to control which matching alert details are used during inference updates. |
When inference-update behavior is enabled in your deployment, a later matched alert can replace the initial inference-driving context and re-enter response/escalation evaluation.
Correlation using time
This section is required and defines how alert sequences are grouped.
| Selection | Behavior and Additional Fields |
|---|---|
| Alert sequence recommended by the machine learning model | Uses learned historical sequence behavior. Recommended default in most deployments with stable data. The UI shows the How it works link and additional ML controls such as continuous learning and topology options. |
| Within time window | Correlates alerts occurring within a fixed duration. The UI expands to show Minutes for the correlation window and optional trigger-based conditions. |
| Alert trigger when it matched with below conditions | Optional trigger control for time-window mode. When selected, the UI shows trigger duration in Minutes, Type, Resource Value, and Alert Metric. At least one of Resource Value or Alert Metric is required. |
Fields shown when machine-learning mode is selected
| Field | Description |
|---|---|
| Enable Continuous Learning | When enabled, the policy keeps learning from recent data over time. |
| Use Topology | When enabled, topology relationship context is considered during correlation decisions. |
| Depth | Topology depth selector (for example 1, 2, or 3) used with Use Topology. |
| Import | Upload sequence input data. The UI also provides a Sample File link. |
| Sequence input | Sequence values are comma-separated metrics. Each sequence should have metrics separated by commas. |
Fields shown when within-time-window mode is selected
| Field | Description |
|---|---|
| Minutes (Window) | Total correlation window duration. |
| Alert trigger when it matched with below conditions | Enables additional trigger constraints for starting correlation. |
| Minutes (Trigger) | Duration used for trigger-condition matching. |
| Type | Trigger attribute type selector (for example Resource Name). |
| Resource Value | Value for the selected trigger type. |
| Alert Metric | Metric-based trigger input. Provide this or Resource Value. |
Operational note: Alerts generated within the configured window can continue to append to the mapped incident until lifecycle boundaries (for example, resolved/closed) are reached.
Sequence and training options
If ML-discovered sequences are not sufficient, you can refine behavior with sequence controls:
- Detected Alert Sequence Patterns to review learned sequences.
- Learn/Unlearn actions to tune sequence behavior.
- Optional CSV-based user sequence training for heuristic matching.
Training file guidance:
- Prefer ML discovery first; add CSV training only for specific gaps.
- CSV supports wildcard patterns (
*) for similar alert names. - Sequence order in each row is significant.
- Sequence learning/unlearning updates can take time to become effective.
ML lifecycle note:
- New or updated policies can pass through states such as awaiting data, queued, training in progress, and ready.
- Correlation value is highest after the policy reaches Ready with sufficient data.
Alerts similarity
Similarity rules define what must match between alerts before they are grouped.
| Field | Description |
|---|---|
| Alert Attribute | Select the alert attribute to compare across candidate alerts, for example Alert Component. |
| Match Operator | Select the matching behavior, for example Identical. |
| + Similarity Rule | Add additional similarity conditions when needed. |
At least one similarity rule is required to complete policy creation.
Recommendation: Start with one strong similarity rule, validate results, then add more only if needed.
After policy creation
Correlation results appear as inferences with unique IDs. From the alert views, teams can:
- Review all correlated alerts for an inference.
- Remove incorrectly grouped alerts.
- Designate an RCA alert where supported.
Save behavior
- Click Add to create the policy.
- Add remains disabled until required fields are complete.
Validation checklist
Before saving, confirm:
- Policy state is correct for rollout stage.
- Policy name clearly identifies logic and scope.
- Time model is selected and duration is intentional.
- Similarity rules are specific enough to avoid unrelated grouping.
- Optional filters are not too restrictive.