Skip to content

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 settings

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

You can 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.

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.