Alerts and Notifications
Overview
There are a number of options available in the Meraki dashboard for email alerts to be sent when certain network or device events occur. This article outlines which options are available for each product and provides additional considerations when using network alerts and organization-wide notifications throughout the dashboard.
Learn more with this free online training course on the Meraki Learning Hub:
Configuring Network Alerts
Network alerts can be configured in dashboard web under Network-wide > Configure > Alerts.
Many network alerts can also be configured in the Meraki mobile app (iOS) (Android), as well as mobile device push notifications for these alerts, detailed below in the section, Mobile App Notifications for Alerts.
Network alerts can be configured by specifying the default recipients for selected alerts and by configuring additional recipients on a per-alert basis. There are two options to denote who will receive email alerts:
- All network admins
This will send email alerts to both full and read-only network admins. This does not include organization admins.
The Account Status of the added Network admins need not be in a verified state to be a recipient of these alerts.
- Other email addresses
This allows for a custom list of recipients, where email alerts are sent to all email addresses listed. To specify other email addresses, type an email address into the default recipients field and hit enter.
All network alerts will be sourced from the same email address. To ensure that alerts are not being lost to a spam filter, please be sure to add alerts-noreply@meraki.com as a trusted email source.
SAML users cannot receive alerts, as they have no email address saved on the dashboard for their account.
Mobile App Notifications for Alerts
The Meraki mobile app (iOS) (Android) offers push notifications to app users for all notifications configured in the app. Notifications can be configured in the app under Settings > Notifications.
Notifications in the mobile app have a few configuration parameters:
- Allow notifications
- On - If on, when this event triggers, notifications for this network can be delivered to all configured recipients. This setting must be on to receive any notifications including email, mobile push, webhooks, or any other receivers.
- Off - If off, when this event triggers, notifications of any type for this network will not be delivered to any configured recipients.
- Receive push notification
- On - If on, when this event triggers, the device this setting is set on will receive OS-based push notifications. Note that this setting varies per device, and is a personal setting rather than a network-wide setting like the others.
- Off - If off, when this event triggers, the device this setting is set on will not receive OS-based push notifications.
- Default recipients
- Default recipients are the recipients who receive notifications for ALL events for this network that have Allow notifications enabled.
- Default recipients will not affect which users receive mobile push notifications, as that setting is configured per-device.
- Additional Recipients
- In addition to (or in the absence of any) default recipients, these users will receive notifications, if Allow notifications is enabled.
Note that notification configurations set in the mobile app also affect notification configurations in dashboard web, and vice versa. However, mobile push notifications are configured per-device rather than network-wide, as mobile push notifications are a mobile-app-only feature.
Network-Wide Alerts
The following alerts can be configured on multiple Cisco Meraki products when:
- Configuration settings are changed
Available on all platforms; sends an email if any configuration change is made in the dashboard. - A VPN connection comes up or goes down
Available on both the MR and MX platforms; this alert will be triggered whenever the configured VPN tunnel status changes, i.e., when it goes up or down. it is also common to receive several VPN email alerts when the tunnels are flapping.
Note: for MX, only AutoVPN connections are monitored for alerts. The connectivity status of non-Meraki site-to-site VPN cannot be monitored from both sides of the tunnel. - A rogue access point is detected
Sends an alert if a rogue access point is detected on the network. - Network usage exceeds (x) KB/MB/GB/TB in 20 minutes/4 hours/1 day
Sends an alert if the specified amount of data is seen on the network for the specified time frame. - Mute wireless alerts based on switch port schedules
If toggled on, then wireless unreachable alerts will be muted when caused by a port schedule.
Wireless Alerts
Alerts can be configured for the following wireless events:
-
A gateway goes offline for (x) minutes
Sends an email if any gateway Access point is unreachable from the dashboard for the configured number of minutes.
Please note that the Access point may still be functioning, this only indicates that it is unable to contact the dashboard.
A "gateway online" alert is only sent if the gateway comes online within 60 minutes of the "gateway offline" alert. - A repeater goes offline for (x) minutes
Sends an email if any repeater Access point is unreachable from the dashboard for the configured number of minutes.
A "repeater online" alert is only sent if the repeater comes online within 60 minutes of the "repeater offline" alert. - A gateway becomes a repeater
Sends an email if a gateway Access point loses its link to the network and comes online as a repeater.
For more information on this behavior, please refer to our documentation regarding Gateway AP Switches to Repeater - Clients have poor signal strength
Sends an email if a client is connected on (x) SSID with 'low/medium/high' signal quality (SNR) for more than 5/15/30/60 min. - Clients with high bandwidth usage.
Sends an email if a client on (x) SSID with 'low/medium/high usage for more than 30 min/2 hour/6 hours/12 hours. - Clients fail to connect to the wireless network
Sends an email if a client using (x) SSID with 'low/medium/high' failure of Assoc/Auth/DHCP/DNS for more than 15 min/30 min/1 hour/2hours - Uplink IPv6 duplicate address detected
Sends an email if the access point detects that two devices use the same IPv6 address
Additional alerts can be configured to maintain visibility on wireless Bluetooth® clients:
Detected devices will be displayed in the Wireless > Monitor > Bluetooth clients page. The name of the Bluetooth® client can also be edited for easier tracking. Email alerts can be enabled to trigger when the device becomes visible by the access point and when the device is no longer visible.
WAN appliance Alerts
Alerts can be configured for the following security appliance events:
- A WAN appliance goes offline for (x) minutes
Sends an email if the MX is unreachable from the dashboard for the configured number of minutes. Please note that the MX may still be functioning, this only indicates that it is unable to contact the dashboard.
A "MX online" alert is only sent if the MX comes online within 60 minutes of the "MX offline" alert. - The primary uplink status changes
Sends an email if the status of the primary uplink changes, which could be a failover event or downed link.
Note: It is not recommended to configure this alert if you are running an security appliance with only a cellular uplink, as you may see false alerts about failing over to a cellular uplink if the node reboots or experiences an issue with connectivity. In such situations, it's recommended to use the cellular connection state alerts.
- The DHCP lease pool is exhausted
Indicates that the MX has run out of available IPs in one or more of its configured DHCP scopes and is unable to provide an IP address to a requesting client. - An IP conflict is detected
Sends an email if the MX has observed traffic from multiple MAC addresses using the same IP address.
Note: Due to the nature of certain device types, this event may occur as a result of normal network behavior. For a common example, please refer to our documentation regarding IP Conflict Events Triggered by iOS Devices. - An IPv6 duplicate address is detected on the WAN uplinks
This alert will be triggered if the security appliance detects that two devices use the same IPv6 address on the WAN uplinks. IP conflicts generally result in connectivity issues for both devices. - A DHCPv6-NA renumber is detected
This alert is triggered when IPv6 Renumbering is detected for DHCPv6 identity association for non-temporary address (IA_NA). - A DHCPv6-PD renumber is detected
This alert is triggered when IPv6 Renumbering is detected for DHCPv6 identity association for prefix delegation (IA_PD). - Cellular connection state changes
Sends an email if the security appliance establishes or loses its connection to the cellular network. - A rogue DHCP server is detected
Sends an email if the MX observes multiple MAC addresses responding to DHCP Discover or DHCP Request messages. This can occur if a DHCP relay server is configured on a VLAN where the MX is configured to respond to DHCP.
For more information, please refer to our documentation regarding DHCP configuration in the dashboard. - A warm spare failover occurs
Sends an email if the primary MX of a high-availability pair fails over to the spare, or vice versa.
For more information, please refer to our documentation regarding Troubleshooting MX Warm Spare. - Malware is blocked
This alert will be triggered when a malicious file download is blocked. - Malware is downloaded
This alert will be triggered when a file previously downloaded on your network is determined to be malicious in retrospect. - Clients connect or disconnect from the LAN
Sends an email if select clients connect or disconnect from the LAN, as observed by the MX. The MX sends an ARP request to the client approximately every ten seconds to monitor its connectivity status. If the MX does not receive an ARP reply from the client after approximately 35 seconds, it considers the client to be disconnected. Once the client begins sending data through the MX and responding to ARP requests, it will again be marked as connected.
Note: This alert is not available on MX security appliance networks that are set to track clients by IP address. Client tracking can be configured in Security & SD-WAN > Configure > Addressing & VLANS > Client tracking.
- VLAN prefix shortage detected
Will be triggered when Prefix Starvation occurs, when the MX detects it does not have enough prefixes from a given WAN or manual configuration to assign a /64 prefix to each IPv6 enabled VLAN
Note: This alert is only available for MXs that can run IPv6. Requirements for IPv6 on MX are covered in the IPv6 Support on MX Security & SD-WAN Platforms document.
- HTTPS inspection certificate error occurs
This error may occur when the security appliance has been factory reset. Re-upload the certificate to restore HTTPS inspection functionality.
Wireless MX/Z-Series Alerts
The following additional alert is available for wireless MX devices or the Z-series teleworker gateway:
-
A rogue access point is detected
Sends an alert if a rogue access point is detected on the network
Switch Alerts
Alerts can be configured for the following switch events:
- A switch goes offline for (x) minutes
Sends an email if a switch is unreachable from the dashboard for the configured number of minutes.
Please note that the switch may still be functioning, this only indicates that it is unable to contact the dashboard.
A "switch online" alert is only sent if the switch comes online within 60 minutes of the "switch offline" alert. - A new DHCP server is detected on the network
Sends an email if a DHCP offer, ACK, or NACK message from a new MAC address (not seen in the last month) is observed by the switch.
The Switching > Monitor > DHCP servers & ARP page displays information about any DHCP servers seen by Meraki switches on the LAN. From this page, administrators can also configure email alerts.
- A client is detected sharing its IP address via NAT
Sends an email if the switch detects an Endpoint that appears to be using Network Address Translation (NAT).
For more information on this behavior, please refer to our documentation regarding NAT Detection on MS Switches. - Any/specific port(s) goes down for more than (x) minutes
Sends an email if the switch port(s) specified goes down for more than the configured number of minutes. A "port connected" email is sent if the port comes up within 60 minutes after the "port disconnected" email was sent. - Any/specific port detects a cable error
Sends an email if the switch port specified detects an issue with the connected cable. - Any/specific port changes link speed
Sends an email if the switch port specified renegotiates or fails over to another link speed.
Note: Alerting for a specific port (or ports) requires the port(s) to be tagged under Switching > Monitor > Switch ports. If no ports are tagged, "any port" will be the only option in the drop-down menu. Please note that multiple ports can share the same tag. Alerts will not be generated for untagged ports if alerts are configured for tagged ports.
- A power supply goes down
Sends an email if one of the removable power supplies on the switch fails. - A redundant power supply is powering a switch
This alert will be triggered if redundant (not modular) power supplies are providing power to a switch. - Unidirectional link detection (UDLD) errors exist on a port
This alert will be triggered if UDLD errors are seen on a switch port. - A switch is operating at critical temperature
This alert will be triggered if a switch detects that it is operating at critical temperature. Critical temperature is a serious scenario requiring consideration of the operating environment of the switch. This alert is supported for the MS120 series (Only MS120-24P, MS120-48LP, and MS120-48FP models are supported. MS120-8 models are not supported), MS125 series, MS130 series, MS220-24P, MS210 series, MS225 series, MS250 series, MS320 series, MS350 series, MS390 series, MS410 series, and MS425 series.
Endpoint management Alerts
Systems Manager offers a number of advanced alert options, unique from the rest of the Meraki product line.
Camera Alerts
Network-wide alerts can be configured for the following camera event:
- A camera goes offline for (x) minutes
Sends an email if a camera is unreachable from the dashboard for the configured number of minutes.
Please note that the camera may still be functioning, this only indicates that it is unable to contact the dashboard.
A "camera online" alert is only sent if the camera comes online within 60 minutes of the "camera offline" alert. - Custom recipients for motion alerts
These users should only get motion alerts and no other Meraki alerts - A camera has a critical hardware failure
A potential hardware problem exists please contact Meraki support to further assist - A camera has a potential issue with Cloud Archive
Sends an email if one or more cameras in the network are detected to have an issue with video upload to Cloud Archive. The email is only sent once for the entire network and not for each individual camera. This alert is enabled by default on all networks which include cameras with cloud archive licenses.
Motion Alerts
Configuring Motion Alerts
- Navigate to Cameras > Monitor > Cameras
- Select a node from the camera list page
- Navigate to Settings > Motion Alerts to configure alerts for this specific node
For an overview of this feature, please see our Motion Alerts article
Sensor Alerts
The MT line of sensors have robust and easy-to-set-up alerts in order to notify a user in the event of configured threshold violations. This is accomplished through the creation and assignment of alert profiles.
For information on setting up MT alert profiles, please see the Sensor Alert Profiles article.
Organization-Wide Alerts/Notifications
Organization alerts can be configured in the dashboard under Organization > Configure > Settings.
For information on setting up organization-wide alerts/notifications, please see our Organization Settings article.
Meraki Insight (MI)
Utilizing Meraki Insight, an MX can be configured to monitor and track traffic associated with specific web applications. This data is tracked on a per-flow basis at the MX, then the relevant flows are aggregated into categorical groups based on their associated application and sent over an encrypted connection to the Meraki Cloud Controller for further analysis before populating that flow data into the Insight feature on the dashboard.
For a detailed overview of this feature please see our MI Web App Health article.
Alert Configuration
For a detailed explanation on configuring MI alerts, please see our MI Overview article.
Additional Alert Considerations
SPAM Filters
- All network alerts will be sourced from the same email address. To ensure that alerts are not being lost to a spam filter, please be sure to add alerts-noreply@meraki.com as a trusted email source.
- All organization-wide alerts will be sourced from the same email address. To ensure that alerts are not being lost to a spam filter, please be sure to add noreply@meraki.com, and noreply-support@meraki.com as trusted email sources.
- All firmware upgrade alerts will be sourced from the same email address. To ensure that alerts are not being lost to a spam filter, please be sure to add support-noreply@meraki.com as a trusted email source.
Receiving Email Alerts via SMS
It is possible to have email alerts forwarded as an SMS to a phone number. This can be configured under the avatar icon (on the top-right of the green ribbon) > My profile > Alerts > SMS notifications. When SMS is enabled, users configured as default recipients in Network-wide > Alerts will receive both email and SMS notifications.
When configuring email recipients, follow the best practices below:
-
Alltel: phonenumber@message.alltel.com
-
AT&T: phonenumber@txt.att.net
-
T-Mobile: phonenumber@tmomail.net
-
Virgin Mobile: phonenumber@vmobl.com
-
Sprint: phonenumber@messaging.sprintpcs.com
-
Verizon: phonenumber@vtext.com
-
Nextel: phonenumber@messaging.nextel.com
- US Cellular: phonenumber@mms.uscc.net
The SMS alerts are limited to nodes going offline, coming online and MT events.
Alert Rate Limiting
All alerts are logged to the Network-wide > Monitor > Event Log and are sent as emails depending on the settings outlined in this article. The alerts listed below are rate limited to 25 alerts per 10 minutes, per event type, per network. This means that if 35 alerts for "Client IP conflict detected" are triggered at the same time in your network, they will all be logged to the event log, but only the first 25 will be sent to your organizations' administrators. This rate-limit also applies to Webhooks.
Alert events that are rate limited:
- DHCP leases exhausted
- Client IP conflict detected
- Cellular came up
- Cellular went down
- Client connectivity changed
- Failover event detected
- Rogue DHCP server detected
- VPN connectivity changed
- Devices operating at critical temperature
- UPS output source changed
- HTTPS inspection certificate error
- Uplink status changed
- Client connected to another network
Syslog, API, Webhooks, and SNMP
A detailed overview and configuration guide of the reporting options in the table above can be found in our Meraki Device Reporting - Syslog, SNMP, and API article.