# Configure case creation and noise-reduction rules Note Cases are in beta. Features may change, and some functionality may be limited. Use **Case settings** to control when Cases are created from alerts and how alert activity is handled before and after a Case is closed. These settings help you reduce noise, avoid repeated Cases for the same issue, and ensure that the Cases view reflects real, actionable problems instead of short-lived or unstable conditions. Note Changes to these settings apply only at Case creation time. Updates affect new Cases only and do not change the behavior of existing Cases. ## Case filtering rules Case filtering rules define which alerts are allowed to create Cases. This gives you control over the volume and relevance of Cases that appear. Use these rules to prevent unnecessary Case creation and to focus attention on the alerts that matter most to your operations. Select one of the following options: ### All alerts Create a Case for every alert source that triggers. Use this option when you want full visibility and prefer to review every triggered alert as a Case, even if some represent brief or low-impact conditions. ### Custom rules Create Cases only when alerts match the attributes you define. Use this option when: - some alerts are more important than others - you want Cases only for specific priorities - certain entity labels are more relevant to your teams Add one or more conditions, such as **Priority** or **Entity label**, and select the values that must match. When multiple conditions are configured, all must match before a Case is created. This ensures that only alerts meeting all selected criteria generate a Case. ### No cases Do not create a Case for any alert that triggers. Use this option when you do not want to manage Cases for alert activity. ## Timing configuration Timing configuration controls when a Case is created and how the system handles repeated alert activity over time. These settings help ensure that Cases represent sustained issues rather than brief or unstable behavior. ### Suppression window Delay Case creation after an alert triggers. This delay allows the system to observe the alert condition before creating a Case. Use this setting to: - avoid creating Cases for alerts that resolve quickly - reduce noise from momentary spikes or fluctuations If the alert resolves during this delay, no Case is created. Configure this delay using **Delay notifications for**. ### Post-resolution cooldown Suppress new Cases for the same alert condition after a Case is resolved. This window helps you: - prevent repeated Case creation when a condition is unstable - group related alert activity into a single Case - avoid opening a new Case immediately after closure Configure this period using **Post-closure suppression window**. ### Inactivity resolution timer Automatically resolve a Case when no meaningful updates occur for a configured period of time. This applies to all Cases, including those that continue to receive alert signals but do not change in status or priority. The system determines inactivity based on the time since the last Case update. Only status changes and priority changes count as Case activity. Repeated alert evaluations that do not change the Case state do not reset the timer. When the inactivity period is exceeded, the system resolves the Case and records the action in the Activity tab with the resolution reason **Resolved due to inactivity**. **Configuration** - Default threshold: 1 day - Configurable range: 1 hour to 1 week This behavior is disabled by default. ## Response Time KPIs Define target response times per priority. Cases exceeding targets show breach indicators. Use Response Time KPIs to give your team a clear target per case priority and a heads-up when a case is taking too long. Targets are configured per priority so higher-priority cases can be held to tighter response times than lower-priority ones. You can configure two KPIs per priority: - **Time to Acknowledge.** The time allowed between case creation and acknowledgement. - **Time to Resolve.** The time allowed between case creation and resolution. Each KPI is enabled independently per priority, so you can hold P1 cases to a tight Time to Acknowledge while leaving Time to Resolve open, or set both for some priorities and neither for others. ### Configure targets 1. Open **Cases settings**. 1. Scroll to **Response Time KPIs**. 1. For each priority you want to track, select the **Case priority** from the dropdown, then enable **Time to Acknowledge**, **Time to Resolve**, or both. Enter a value and select **Minutes** or **Hours** from the unit dropdown. 1. Select **Add KPI** to add a row for another priority. Use the trash icon on a row to remove its targets. 1. Select **Save changes**. A KPI with the checkbox cleared is not evaluated for that priority, even if a value and unit are entered. Use the checkbox to turn tracking on or off without losing the configured value. ### How breaches surface When a case misses one of its enabled targets, the system records the breach and surfaces it in three places: - A **Needs attention** filter on the Case list groups every case that has missed a target. - A **KPI Breached** event is added to the case **Activity** timeline with the KPI, priority, and the time spent in the missed state. - A **KPI status** field is included on the notifications routed for the case, listing each configured KPI alongside its current state. See [Working with Cases](https://coralogix.com/docs/user-guides/cases/working-with-cases/index.md) for details on each surface. ## How Case status appears during failures When a Case remains open and the alert condition continues to fail, the Case view provides additional information to help you understand the situation. **Failing for** Shows how long the condition has been continuously failing. **Failing since** Shows the time when the failure began. **Condition evaluation** Shows the current evaluated values compared to the defined condition. Together, these fields help you: - understand how long the issue has persisted - identify when the problem started - confirm that the alert condition is still being met This context supports more informed triage and resolution decisions. ## How these settings work together Case filtering rules control which alerts can create Cases. Timing configuration controls when those Cases are created and how repeated activity is handled. By combining these settings, you can: - reduce unnecessary noise - avoid duplicate Cases - keep the Cases view focused on sustained, meaningful issues These controls make Case behavior predictable and easier to manage across your environment. ## Related resources [Cases overview](https://coralogix.com/docs/user-guides/cases/overview/) [Set up Cases](https://coralogix.com/docs/user-guides/cases/quick-start/) [Working with Cases](https://coralogix.com/docs/user-guides/cases/working-with-cases/) [Configure alert definitions](https://coralogix.com/docs/user-guides/alerting/configuring-alert-definition/) [Routing rules](https://coralogix.com/docs/user-guides/notification-center/routing/define-routing-rule/) ## Next steps Synchronize Cases with ServiceNow for bi-directional lifecycle management in [Cases ServiceNow integration](https://coralogix.com/docs/user-guides/cases/sn-integration/index.md).