Actions (Organization Alerts and Alert Hub)
The Early Access for the new Actions page, which will be replacing the Organization Alerts page, is now open. This is a tiered rollout, check back if you don't see the switch to enable. The first part of this document gives an overview of the value of the Actions page and it's part (diagnose and remediate) in the overall Agentic loop for Sensing, Diagnose, Remediate, and Validate.
Overview
The "Actions" document outlines a centralized framework for identifying and managing network health, categorized into three distinct signal types: Incidents, Alerts, and Optimizations. This system is designed to help administrators prioritize their workload based on the severity and impact of network issues, with research confirming that users prefer an "inbox-style" approach for effective troubleshooting. By organizing signals by urgency and providing robust filtering and navigation capabilities, the platform ensures that users can focus on critical issues while maintaining a proactive stance on network improvements.
To facilitate efficient remediation, the system provides AI-generated briefings, actionable recommendation cards with confidence and risk assessments, and a comprehensive reasoning log for auditability. Users can interact with this through multiple entry points, Org/Assurance Actions pages, alert hub, and contextual entry points (e.g. device details or XM page), allowing for seamless transitions between high-level overviews and granular troubleshooting. These features, combined with flexible configuration options for external notifications, aim to empower administrators to resolve network issues with clarity, speed, and confidence.
Entry Points
There are 3 entry points for getting to the Actions page
- Left navigation menu Assurance >> Actions for Network scoped page and Organization >> Actions for Organization scoped page. This replaces the existing Alerts page.
- Experience Metrics page when an incident is identified and associated
- Device Details page
Signal Types
There are different signal types to help users prioritize:
- Incident: A high-severity network issue that is persistent, has high client impact, and a correlated root cause.
- Alert: A detected network state change indicating a potential degradation, with suggested steps to remediate the issue (e.g. VLAN mismatch)
- Optimization: A proactive opportunity to improve the network, but is not time-sensitive and does not currently have impact on the network (e.g. enable auto RF)
Navigation
Users can use a variety of filters and navigation patterns to triage and focus on specific signals:
- Filters
- Time range
- Signals (incident, alerts, optimizations)
- Status (active, dismissed, resolved)
- Network
- Severity (critical, warning, information) – alerts only
- Signal type - alerts & optimizations only
- Device type - alerts only
- Device tag - alerts only
- Group by (varies depending on signal type selected)
- Signal type
- Network
- None
- Sort by (varies depending on signal type selected)
- Most recent
- Impact
- Severity
- Count
- List view / Table view switcher
- Alert configuration
List View
List view allows users to view the action list on the left (e.g. list of alerts) and act within the action panel on the right, similar to an email inbox. Within the list view, there are:
- Action list: the left side of the page where users can see a list of actions with tabs for Incidents, Alerts, and Optimizations
- Action panel: the right panel where users can take action to remediate the issue
Requirements for classification of an Incident:
- High client impact (count): A validated, persistent, and correlated issue affecting a significant percentage of clients, linked to a a common root cause via the anomaly detection model.
- High confidence actions: The system has high confidence that the suggested remediation steps will resolve the issue
Action List
Actions are grouped to ensure it scales to large orgs.
- Group by and sort by options vary depending on the signal type selected
The metadata includes:
- Impacted entities (clients & devices)
- Network
- Signal type
- Device name
- Device type
Action Panel
Action Panel allows users to dive into the specific issue to act and remediate it. It includes several sections that update as users progress through the troubleshooting flow.
Users can access the action panel in a few ways:
- From the Actions page as a centralized hub to view all their actions
- From contextual in-product entry points (e.g. XM page or device details page) where they can open a side panel with the same content
- From the alert hub bell icon, which opens a side panel with the same content
Header
The header includes metadata to help users anchor on the information they are viewing.
Briefing
Briefing is AI-generated summary to give users an overview of the issue, root cause, and remediation outcomes.
- Active state: summarizes the issue and the root cause
- Resolved state: summarizes the issue and the resolution
- Visual: any visual evidence, if available, to support the briefing
Recommended Actions
The Recommended Actions card shows suggested actions to remediate the issue.
Components of the action card:
- Estimated time to complete the actions
- Calls out whether the action will cause potential network disruptions
- Anchor links to view details below in the reasoning log
The card supports users taking a single action or multiple actions.
- For a single action, there will be one CTA (Call to Action)
- For multiple actions, there will be individual CTA next to each action
As actions are carried out:
- There will be a progress bar to show status and verify whether the issue has been resolved
- Once the actions have been completed, we will indicate completion with a check mark
Reasoning log
The reasoning log provides a detailed chain of evidence, root cause, and action outcomes for users to audit and reference. The individual evidence cards make up the audit trail.
Components of the reasoning log:
- Evidence cards that make up the audit trail, which can include the initial metric being degraded, root cause identified, action taken, and the issue being resolved
- Time series vs. non-time series
- For logs that have a sequential time series, the reasoning log will be presented as a timeline with time stamps for each evidence
- For logs are time-agnostic, it will show all the evidence regardless of the time
- Sources: each evidence card includes a source for users to dive deeper into specific pages
As additional evidence, data, or actions come in, it will be appended to the reasoning log to create an audit trail. Even when the issue is resolved, users can still reference the reasoning log to trace historical issues.
Action Drawer
Users can access the action panel in-context of their workflow, via a “Suggested actions” button entry point on the Device page alert in the left hand column that opens an action drawer within the user’s existing workflow.
Deep Reasoning Agent (DRA) Integration
Incidents and Alerts
- Deep Reasoning is a sophisticated AI-driven diagnostic process designed to handle complex network and security issues that simple playbooks cannot solve. It uses a self-correcting approach grounded in a library of Cisco-authored standardized networking skills, which encodes the diagnostic methodology and decision logic an experienced network engineer would apply.
- Incidents are pre-loaded with contextual data and analysis before the user accesses them. This means that when a user opens an incident, the relevant information, including telemetry, logs, and preliminary AI-generated summaries, is already available. This pre-loading eliminates waiting for data retrieval or initial processing. It enhances operational efficiency by reducing delays and allowing users to respond faster to incidents.
- Unlike incidents, alerts are generated dynamically and loaded on demand when a user requests them. Because alerts often require real-time analysis and synthesis of telemetry data and AI reasoning, the content must be generated at the time of the request. This on-demand loading means users may experience some wait time while the system processes and compiles the alert details. This approach balances resource usage by not pre-loading all alerts but may introduce latency when accessing alert information.
- After a user triggers 10 deep reasoning agent interactions by opening an Incident/Alert in the Actions page or Actions side drawer (within a single calendar day) the system will display a message informing the user about potential future usage limits. The message aims to increase user awareness of consumption patterns and encourage efficient use of deep reasoning capabilities, but currently no hard limits are enforced.
Configuration
Users can now configure Alert Rules, Alert Profiles, and Schedules via Actions List gear icon.
Alert Rules
Alert rules provide a centralized interface where you can enable or disable individual or multiple alerts at once. Additionally, you can configure the notification settings by specifying email recipients and webhook endpoints to receive event notifications. This allows you to control which alerts are active and how alert notifications are delivered, ensuring that the right people or systems are informed promptly. The interface typically supports both single alert edits and bulk edits for efficient management, including setting thresholds and muting alerts as needed.
Alert Profiles
Alert profiles allow you to group multiple alerts and configure how they respond by setting elements such as schedules, maintenance mode, and enabling or disabling various notification channels. This grouping enables targeted management of alerts, for example, to address specific alerts on particular networks efficiently. Through alert profiles, you can customize alert behavior and notification delivery to suit different operational needs and network contexts, including muting alerts during maintenance periods or scheduling when alerts are active. This centralized approach simplifies managing alert responses across different networks and notification preferences.
Alert Schedules
Alert schedules enable the creation of time-based scheduling objects that can be applied to alert profiles, providing context for when alerts should be active or muted. This functionality supports scenarios such as non-working hours, school schedules, and regular maintenance windows, allowing alerts to be managed according to specific time frames and operational needs. By using alert schedules, organizations can ensure that alerts are delivered or suppressed appropriately based on predefined time windows, improving alert relevance and reducing unnecessary notifications during planned downtime or outside business hours.
Alert Hub
Alert hub consolidates all the alerts from a single dashboard network.
Location
The alert hub is located in the top right corner of the dashboard. It is a network-wide feature, so this feature is not available on any pages under “Organization".
Clicking on the icon will show a popover summary of network alerts.
- Organization Alerts Page: Lists summary of alerts across all networks within your given organization.
- Alert Category: Organizes alerts by category, such as device health, connectivity, insights, etc.
- Troubleshooting Documentation: Allows for easy access to documentation on dashboard alerts.
- Severity Level: Displays the severity level of the alert.
- Alert Instances: Displays the number of times the given alert has been triggered.
- Alert Type: Displays the type of alert triggered.
- Alert Dismissal Button: Dismisses the alert from Alerts hub.
- Alert Triggered Timestamp: Displays the time and date the alert was triggered.
- Alert Hub Feedback: Provides an opportunity for user feedback to be reported directly to our software team.
Organization Alerts Page
The organization alert page displays a timeline/trend line, analytics graphs, and all dashboard alerts of an organization in a single place.
Location
The organization alert page is located under Organization > Monitor > Alerts.
Alert Categories
The alert hub categorizes alert types into four different categories based on the nature of the issue that triggers them. Direct cross links allows for quicker research in the Knowledge Base for details about the alerts.
Configuration Issues - These issues are triggered if the current setting or configuration differs from Cisco Meraki recommendation. (e.g: VLAN mismatch, Stack misconfigured, etc)
Connectivity Issues - These issues are triggered if there are problems in connectivity between devices/services. (e.g: Device unreachable, 802.1X failure, etc)
Device Health Issues - These issues are triggered if a device detects problems with its primary or auxiliary systems. (e.g: fan failure, power supply offline, etc)
Insights - These issues are triggered if Cisco Meraki detects problems with LAN/WAN services. (e.g: Sticky client on APs, ISP outage, etc)
Cisco Meraki might add more categories if needed to accommodate more alerts in the future.
Alert Severity
There are several alert types under each category. All the devices with the same alert type will be listed together in their respective alert type card.
Different colors are used for visual indication of severity levels as following:
-
Warning : Yellow - alerts that need attention, but are not imminently critical to network performance/communication. -
Critical : Red - alerts that indicate a critical failure has occurred or imminent failure is likely soon. -
Dual : Yellow/Red alerts that posses variable severity, alert has 2 (two) thresholds and will trigger appropriate severity as thresholds are crossed -
Informational : Blue - a non-critical alert that provides information about an event or status change without requiring immediate action.
Instances: This is only applicable to the alert hub. A single occurrence of an alert is considered as one instance. For example, an unreachable device under “Unreachable Device(s)” alert type is regarded as one instance. If there is more than one device unreachable then the list of devices/instances will show up under the same alert type. Count of devices/instances are shown next to the alert type.
Bundled Alerts
Bundled alerts are contextually linked to the time range filter at the top of the page, for more information see Alert Filters section below
Active Alerts
The “Active” tab lists active (initiated within time range) dashboard alerts in an organization
Dismissed Alerts
When alerts are dismissed either in the Alert Hub or in Organization Alert Page, they will be bundled and displayed in the Dismissed bundle tab
Dismissing an Alert
There are two (2) methods for dismissing an alert from the Dashboard, depending on your administrative rights. At the network level from the Alert Hub (as previously shown above) and from the the side drawer in the Organization Alert Page itself.
Alert Hub:
Organization Alert Page - Side Drawer:
Resolved Alerts
When alerts are resolved they will be moved to the Resolved tab
Restoring (Dismissed) Alerts
With Administrative rights, alerts can be restored to the active alert tab, from the Dismissed Alert side drawer. This can be useful if an alert is dismissed by accident.
Alert Filters
Filters are only available for the organization alert page. The time range filter is at the top of the page next to the Alert page title. This filter modifies the context of the entire page for the time range selected.
Important note: All selections, with the exception of All time, show alerts that were initiated within that time frame. All time shows all active alerts regardless of when they were initiated. This is the expected behavior. Last 2 hours is the default selection.
Network filters
This dropdown filter allows administrators to view alerts of a single network or all networks.
Alert and Device Type filters
The alert type filter allows administrators to filter by certain alert types. The device type filter allows administrators to filter by a certain device type (MX, MR, MS, etc.)
No Alerts Indicator
Depending on the filters selected, no alerts may be seen from this page. Ensure to utilize the Time Range filter when viewing alerts from the Alert Hub as an active alert may have originated before the Time Range filter currently selected.
If the organization alert page and the alert hub are not showing any alerts that does not mean that there are no active alerts in the network. Please note that not all the alerts or event logs are available in the alert hub. For the list of available alerts, please refer to the individual alert category documentation hyperlinked in the alert category section of this document.
Feedback
There is a "Give your Feedback" and "Give feedback about these alerts" buttons on the organization alert page and the alert hub respectively which administrators can use to provide feedback on the feature.
Give your feedback button might not work with a few select ad blockers. If you would like to provide feedback please disable ad blocker temporarily.