[🐛 Bug]: I set alert threshold to 3 in Correlation - But only one alert found in the incident created.

[tmqu130]

Describe the bug
I use correlation to group alerts into an incident. I set: several "OR" condition, with alert threshold is 3, but in the Incident created, there is only alert (from the last OR condition).

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

[dosubot]

Based on the code and documentation, the alert threshold in correlation rules should apply to the total number of alerts matching any of your "OR" conditions—not just the last condition. If you set the threshold to 3, the system is supposed to group all alerts matching any of the "OR" branches and only create an incident if at least 3 such alerts exist. The fact that only one alert (from the last "OR" condition) appears in your incident suggests a likely bug in how the aggregation or threshold logic is being applied, possibly only considering the last branch or not aggregating matches correctly across all conditions. This is not the intended behavior according to the correlation engine's design and documentation (source).

There are no recent issues or pull requests addressing this specific bug, and no documentation describes this as expected. You may want to double-check your rule configuration for grouping criteria or misconfigurations, but if everything looks correct, this is likely an implementation issue in the correlation logic.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[tmqu130]

@dosu

There is another problem, I wanna use the operator "Contains" in the search bar on Feed.
So I enter labels.description.contains('QUAN TEST') - I have record with description field as '123 QUAN TEST 123'.
But it didn't work. Do I do it wrong?

[dosubot]

The contains operator is supported in the Feed search bar, and your syntax—labels.description.contains('QUAN TEST')—is correct for substring matching, even for label fields. This should match any description containing "QUAN TEST", regardless of position or case, as it's translated to a case-insensitive SQL search in the backend (docs).

If it isn't working, check for these common issues: make sure the field is actually named labels.description (no typos or case mismatches), confirm the data is fully ingested and indexed, and try searching for a smaller substring like labels.description.contains('QUAN'). Also, check for any extra spaces in your search string or in the data itself. If none of these help, there could be a data mapping or ingestion issue rather than a problem with the search syntax or operator support.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[tmqu130]

@dosu
There's another issue with the content in the Incident tab created with Correlation - There would be several incidents, several alerts, so is there a good search engine for those in the Incident tab?

With each alert pushed into Keep, I added a label to obj_id (device names), and in the Incident tab, I added a facet using this labels.obj_id field. However, it didn't work.

How can I search for Incidents from alerts' information?

[dosubot]

The Incident tab supports faceted search and filtering by incident fields and some alert properties, but not all alert label fields are available by default. Fields like alert.labels.monitor can be used as facets, but arbitrary labels such as labels.obj_id are not automatically indexed for incident-level search or filtering. That's why adding a facet for labels.obj_id didn't work for you—this field isn't exposed in the incident index unless you explicitly map or enrich it into the incident during creation.

To make alert label fields like obj_id searchable or usable as facets in the Incident tab, you need to enrich or map them into the incident model at the time the incident is created. This typically involves customizing your correlation or enrichment workflow to copy the relevant alert label into a dedicated incident field or into the incident's enrichments, so it becomes available for search and faceting. For more on supported facets and how to configure them, see the facets documentation.

If you want to check which fields are available for incident faceting, use the "Add facet" dialog and review the property path suggestions. If your desired alert label isn't listed, it means it's not indexed for incidents yet and needs to be mapped as described above.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[tmqu130]

@dosu
There is an issue: I upload my alert from clickhouse to Keep to show on feed with this workflow:
workflow:
id: clickhouse-push-critical-alerts-to-keep
name: Push New Critical Alerts from ClickHouse to Keep
description: "Lấy các alert critical mới từ bảng ds_alert, đẩy lên Keep Feed"
disabled: false
triggers:
- type: interval
value: 1m
consts:
workflow_tag: alerts
steps:
- name: get-new-critical-alerts
provider:
type: clickhouse
config: "{{ providers.alert-incidents }}"
with:
query: "SELECT
\ any(id) AS alert_id,
\ tags,
\ lower(severity) AS severity,
\ topo_set,
\ formatDateTime(toTimeZone(created_at, 'Asia/Ho_Chi_Minh'), '%Y-%m-%d %H:%i:%s') AS event_date,
\ description,
\ noc_extra_f1,
\ topo_ots_set,
\ service_index,
\ topo_ring_set,
\ obj_id,
\ ots_ring,
\ region,
\ province,
\ pop_id,
\ device_type,
\ service,
\ device_group,
\ hostname
FROM alert_incidents.ds_alert
WHERE created_at >= now() - INTERVAL 6 MINUTE
GROUP BY
\ tags,\
\ severity,\
\ topo_set,
\ event_date,
\ description,\
\ noc_extra_f1,\
\ topo_ots_set,\
\ service_index,
\ topo_ring_set,\
\ obj_id,\
\ ots_ring,\
\ region,\
\ province,\
\ pop_id,
\ device_type,\
\ service,\
\ device_group,\
\ hostname
FORMAT JSONEachRow;\n"
actions:
- name: create-alert-on-keep-feed
foreach: "{{ steps.get-new-critical-alerts.results }}"
provider:
type: keep
config: "{{ providers.default-keep }}"
with:
alert:
name: "{{ foreach.value.obj_id }}"
status: firing
severity: "{{ foreach.value.severity }}"
description: "{{ foreach.value.description }}"
timestamp: "{{ foreach.value.event_date }}"
labels:
alert_id: "{{ foreach.value.alert_id }}"
tags: "{{ foreach.value.tags }}"
topo_set: "{{ foreach.value.topo_set }}"
noc_extra_f1: "{{ foreach.value.noc_extra_f1 }}"
topo_ots_set: "{{ foreach.value.topo_ots_set }}"
service_index: "{{ foreach.value.service_index }}"
topo_ring_set: "{{ foreach.value.topo_ring_set }}"
obj_id: "{{ foreach.value.obj_id }}"
ots_ring: "{{ foreach.value.ots_ring }}"
region: "{{ foreach.value.region }}"
province: "{{ foreach.value.province }}"
pop_id: "{{ foreach.value.pop_id }}"
device_type: "{{ foreach.value.device_type }}"
service: "{{ foreach.value.service }}"
device_group: "{{ foreach.value.device_group }}"
hostname: "{{ foreach.value.hostname }}"
description: "{{ foreach.value.description }}"
timestamp: "{{ foreach.value.event_date }}"
workflow_tag: "{{ consts.workflow_tag }}"
fingerprint: "{{ foreach.value.alert_id }}"

I would push a batch of data each time, dedup by the fingerprint alert_id. However, the information of alerts in each batch pushed to Feed is all replaced with the information of the last record/alert of the batch.
That's why I added labels to every field, so that I can filter them with facet. But the information of the alerts themselves is still incorrect. Did I write the workflow wrong? How can I achieve the right information?

[dosubot]

The issue is with deduplication: Keep uses the fingerprint field to uniquely identify alerts. In your workflow, fingerprint is set to alert_id, but your ClickHouse query uses any(id) AS alert_id with GROUP BY, which can result in duplicate alert_ids within a batch. When multiple alerts share the same fingerprint, only the last one is kept—others are overwritten—so you see only the last alert's data in Feed.

To fix this, make sure each alert in your batch has a unique fingerprint. You can do this by adjusting your ClickHouse query to select a truly unique id for each alert (for example, by not using any(id), or by including more unique fields in the GROUP BY or fingerprint). This will ensure each alert is ingested and displayed correctly in Feed, and faceting will work as expected. More details on how deduplication and fingerprinting work in Keep are in the docs: deduplication, alert evaluation.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[tmqu130]

@dosu
In the correlation function, how to use IN operator, can I fill: the value field as: quantest,minhtest?

[dosubot]

For the IN operator in correlation rules, you need to provide the value as an explicit array, not as a comma-separated string. So instead of quantest,minhtest, use ["quantest", "minhtest"]. If you enter a comma-separated string, it will be treated as a single value, not a list, and won't match as expected. The array format is required for correct rule evaluation.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[tmqu130]

@dosu
After I added the correlation rule, with all the filters needed, I turn back to that rule, the value in the filter is blank.

[dosubot]

This is likely a UI bug or a format mismatch between how the backend saves the filter value and how the frontend expects to read it, especially for operators like IN or when using arrays. The value is probably still saved in the backend (inside the CEL or SQL query), but the UI doesn't re-populate the field correctly when you edit the rule. This issue has been seen before and was fixed in some cases by improving UI state management and data fetching logic, but it can still happen if the value format isn't handled consistently between backend and frontend (example fix, related issue).

As a workaround, double-check that you use the expected format (for IN, always an explicit array like ["quantest", "minhtest"]) and try re-entering the value if it appears blank. If the problem persists, it's likely a UI rendering issue rather than a problem with your configuration.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[tmqu130]

@dosu
Is there a way to prevent concurrency running workflows?

[dosubot]

Keep doesn't currently have a built-in way to prevent concurrent executions of the same workflow—there's no user-facing setting or mutex for this yet. There is an open feature proposal to add workflow dependencies and a "waiting" status that could help with concurrency control, but it's not implemented at this time (discussion).

For now, you can work around this by managing triggers externally (for example, using an external scheduler to avoid overlap), or by adding a custom state check at the start of your workflow (such as checking a lock in a database or cache before proceeding). Also, designing your workflow steps to be idempotent can help minimize issues if two runs overlap.

If you want help with a specific workaround for your use case, let me know!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}