# Alert summary cards, and search and filters on every Discover page

> Alert Monitor and Alert Rules now include summary cards and the standard time range picker, and Discover Databases gains search, sorting and filtering.

Source: https://last9.io/changelog/alert-summary-cards-and-search-and-filters-on-every-discover-page/

Alert Monitor and Alert Rules now have a summary strip, so you can read the state of your alerting without scanning the table.

![The Alert Monitor summary cards, counting firing rules, firing instances, breach instances, acknowledged alerts, and muted rules](../../assets/content/changelogs/alert-summary-cards-and-search-and-filters-on-every-discover-page/alert-monitor-summary-cards.jpg)

- Alert Monitor counts firing rules, firing instances, breach instances, acknowledged alerts, and muted rules.
- Alert Rules counts total, error, muted, and disabled rules, across the org rather than over the filtered table.
- Firing rules and firing instances describe current state, and drop to zero once everything resolves. Breach instances, acknowledged, and muted rules describe the window, and keep counting an alert that has since resolved.
- A click on a card filters the table to exactly the rows that card counted.
- Alert Monitor uses the same time range picker as the rest of the app, with a 14-day floor for retention. An existing Alert Monitor link that carries a `timestamp` parameter still resolves to a valid range.

### Improvements

- **Discover**
  - Search, sorting, and filtering on Discover Databases.
  - Every Discover page and Synthetic Monitoring share one filter sidebar, with the same typography, colors, spacing, empty state, loading state, and applied-filter cue. Table fonts are consistent across the same pages.
  - The user on an Applications (RUM) view resolves from the mobile SDK's `user.name` field as well as web RUM's `user.full_name`.
- **Metrics**: A range query accepts a `data_points` target, so a wide time window comes back at a coarser step that keeps data in every bucket, including for a low-traffic service. A `step` you pass acts as the floor when both are given, and `$__rate_interval` is substituted on the server so the selector always moves with the step.
- **Agents**
  - Trace queries take a distinct-count aggregate, so a question like how many distinct sessions or users a service saw is answered in one query.
  - `get_logs` and log attribute discovery reject a malformed log pipeline locally, before any request goes upstream, so a bad query fails once with a clear message.
  - `get_service_performance_details` returns a coarser, bounded result over a long time range, so a wide-window answer fits in the agent's context.

### Fixes

- **Discover**
  - Applications (RUM) session details hid the custom-event logs of a view whose span was never exported, so events that were already ingested were unreachable.
  - Applications (RUM) session details showed 2 custom events for a view that contained 11, when the custom-event log window only partly covered the view.
  - An Android WebView that resumed was not rebound, so its events were divided between the correct URL row and an extra `WebViewActivity` row.
  - A service dashboard showed an error page when its apdex alert threshold was 0.94 or higher.
- **Alerting**
  - Reopening a saved rule in a Schedule Search alert group showed an empty or unrelated query in the editor.
  - The Slack app could not be enabled because of a permissions problem.
- **Agents**
  - `$notnull` on a span or resource attribute matched zero spans and returned no error, so a query for spans that have an attribute came back empty.
  - An unknown filter operator, such as a typo, was dropped rather than rejected, so the query matched every span.