openshift-docs/modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc

// Module included in the following assemblies:
//
// * observability/monitoring/managing-alerts.adoc

:_mod-docs-content-type: CONCEPT
[id="searching-alerts-silences-and-alerting-rules_{context}"]
= Searching and filtering alerts, silences, and alerting rules

You can filter the alerts, silences, and alerting rules that are displayed in the Alerting UI. This section provides a description of each of the available filtering options.

[id="understanding-alert-filters_{context}"]
== Understanding alert filters

The *Alerts* page in the Alerting UI provides details about alerts relating to default {product-title} and user-defined projects. The page includes a summary of severity, state, and source for each alert. The time at which an alert went into its current state is also shown.

You can filter by alert state, severity, and source. By default, only *Platform* alerts that are *Firing* are displayed. The following describes each alert filtering option:

* *State* filters:
** *Firing*. The alert is firing because the alert condition is true and the optional `for` duration has passed. The alert continues to fire while the condition remains true.
** *Pending*. The alert is active but is waiting for the duration that is specified in the alerting rule before it fires.
** *Silenced*. The alert is now silenced for a defined time period. Silences temporarily mute alerts based on a set of label selectors that you define. Notifications are not sent for alerts that match all the listed values or regular expressions.

* *Severity* filters:
** *Critical*. The condition that triggered the alert could have a critical impact. The alert requires immediate attention when fired and is typically paged to an individual or to a critical response team.
** *Warning*. The alert provides a warning notification about something that might require attention to prevent a problem from occurring. Warnings are typically routed to a ticketing system for non-immediate review.
** *Info*. The alert is provided for informational purposes only.
** *None*. The alert has no defined severity.
** You can also create custom severity definitions for alerts relating to user-defined projects.

* *Source* filters:
** *Platform*. Platform-level alerts relate only to default {product-title} projects. These projects provide core {product-title} functionality.
** *User*. User alerts relate to user-defined projects. These alerts are user-created and are customizable. User-defined workload monitoring can be enabled postinstallation to provide observability into your own workloads.

[id="understanding-silence-filters_{context}"]
== Understanding silence filters

The *Silences* page in the Alerting UI provides details about silences applied to alerts in default {product-title} and user-defined projects. The page includes a summary of the state of each silence and the time at which a silence ends.

You can filter by silence state. By default, only *Active* and *Pending* silences are displayed. The following describes each silence state filter option:

* *State* filters:
** *Active*. The silence is active and the alert will be muted until the silence is expired.
** *Pending*. The silence has been scheduled and it is not yet active.
** *Expired*. The silence has expired and notifications will be sent if the conditions for an alert are true.

[id="understanding-alerting-rule-filters_{context}"]
== Understanding alerting rule filters

The *Alerting rules* page in the Alerting UI provides details about alerting rules relating to default {product-title} and user-defined projects. The page includes a summary of the state, severity, and source for each alerting rule.

You can filter alerting rules by alert state, severity, and source. By default, only *Platform* alerting rules are displayed. The following describes each alerting rule filtering option:

* *Alert state* filters:
** *Firing*. The alert is firing because the alert condition is true and the optional `for` duration has passed. The alert continues to fire while the condition remains true.
** *Pending*. The alert is active but is waiting for the duration that is specified in the alerting rule before it fires.
** *Silenced*. The alert is now silenced for a defined time period. Silences temporarily mute alerts based on a set of label selectors that you define. Notifications are not sent for alerts that match all the listed values or regular expressions.
** *Not Firing*. The alert is not firing.

* *Severity* filters:
** *Critical*. The conditions defined in the alerting rule could have a critical impact. When true, these conditions require immediate attention. Alerts relating to the rule are typically paged to an individual or to a critical response team.
** *Warning*. The conditions defined in the alerting rule might require attention to prevent a problem from occurring. Alerts relating to the rule are typically routed to a ticketing system for non-immediate review.
** *Info*. The alerting rule provides informational alerts only.
** *None*. The alerting rule has no defined severity.
** You can also create custom severity definitions for alerting rules relating to user-defined projects.

* *Source* filters:
** *Platform*. Platform-level alerting rules relate only to default {product-title} projects. These projects provide core {product-title} functionality.
** *User*. User-defined workload alerting rules relate to user-defined projects. These alerting rules are user-created and are customizable. User-defined workload monitoring can be enabled postinstallation to provide observability into your own workloads.