Skip to content

Explore Alerts

The Alerts tab of the Unified Alerts View is where responders triage what’s firing right now. It lists every alert produced by your rules across the selected data sources — OpenSearch log alerts and Prometheus metric alerts in one queue.

The Unified Alerts View Alerts tab, with the filter rail, severity-colored alert timeline, and the list of active alerts

Each row shows an alert’s severity, state, message, and how long it has been active. Sort or search to find a specific alert. Select an alert to open its detail panel — Alert Details, Labels, Annotations, and Raw Alert Data — with an Open rule button that jumps to the rule that produced it. To edit, disable, or delete that rule, use the Rules tab.

The histogram at the top of the tab buckets firing alerts over the selected time range (default Last 24 hours), colored by severity. Use it to spot bursts — a spike of critical bars usually lines up with an incident. Narrow the time range to zoom into a window of interest.

The left rail scopes the list without editing any query:

  • Datasource — pick the OpenSearch cluster (its monitors), the Prometheus data source (its alerts), or both.
  • Severitycritical, high, medium, and so on, with live counts.
  • Stateactive, muted, and (for OpenSearch) resolved.
  • TypeLog, Metric, APM, Cluster Metrics (see Rule types).
  • Labels — every label present on the current alert set (alertname, component, service, job, …) becomes a facet. This is where Prometheus label cardinality pays off: filter to one service, one exporter, or one component in a click.

By default both the OpenSearch cluster and the Prometheus data source are selected. Untick one in the Datasource filter to scope to a single engine. The tab counts update immediately.

Firing metric-rule (Prometheus) alerts are grouped and delivered through the Prometheus Alertmanager. You can inspect that route tree on the Routing tab — see Routing. OpenSearch log-rule, APM, and cluster-metrics alerts instead notify through the actions attached to each rule’s triggers.

If the Alerts tab is empty, nothing is currently firing for the selected data sources. Confirm the right data sources are selected in the filter, create a rule, or generate some load so alerts have something to fire on.

If a rule exists and is enabled but never produces an alert, work through this checklist. Open the rule from the Rules tab to see its definition while you check:

  1. Is the rule enabled? A disabled rule never evaluates. Check its status in the Rules catalog.
  2. Does the query return data? For a log rule, use Run preview in the rule editor — if it returns no rows, the condition can’t trip. Confirm data is actually flowing into the queried indices (logs-otel-v1*, otel-v1-apm-span*) or Prometheus.
  3. Is the condition threshold right? A Number of results trigger fires on the row count; a Custom condition fires when a where clause matches an aggregated value. Make sure your stats/threshold combination can actually be satisfied — see Trigger conditions.
  4. Has enough time passed? The rule only evaluates on its schedule (log rules) or evaluation interval (metric rules). A metric rule also has a pending period / For Duration — the condition must hold continuously for that long before the alert becomes active.
  5. Right time window? Log-rule queries are bounded by the selected time field; a wrong or empty time field means no matching documents.
  6. Right data source selected? Confirm the alert’s data source isn’t filtered out of this view.

If the rule fires but no notification arrives, the rule is working and the problem is delivery — see Notifications → Verify delivery.

  • Explore Rules — browse the rules catalog and inspect definitions.
  • Create Rules — build the log and metric rules that populate this list.
  • Notifications — route firing alerts to Slack, email, PagerDuty, and webhooks.
  • Unified Alerts View — overview, rule types, and classic monitors.