Skip to main content
Cisco Meraki Documentation

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:

MR Advanced Operations

Sign in with your Cisco SSO or create a free account to start training.

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.
  • 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.

 Default recipient alert settings under Network-wide > Configure > Alerts

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.

Screenshot 2023-11-14 at 2.02.52 PM.png

Screenshot 2023-11-14 at 2.03.17 PM.png

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.

Network-wide alert settings under Network-wide > Configure > Alerts


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

Wireless alert settings under Network-wide > Configure > Alerts 

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.

clipboard_e01daee14ec0b7b078ad6b17800c48c3c.png


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.

Security Appliance alert settings under Network-wide > Configure > Alerts

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, MS125 series, MS220-24P, MS210 series, MS225 series, MS250 series, MS320 series, MS350 series, MS410 series, and MS425 series.

Switch alert settings under Network-wide > Configure > Alerts


Endpoint management Alerts

Systems Manager offers a number of advanced alert options, unique from the rest of the Meraki product line.

Several alerts can be configured to inform you and other network administrators of modifications made to your Systems Manager network. On a standalone Systems Manager network, these can be configured under Systems Manager > Configure > Alerts. In a combined network, all alerts are configured under Network-wide > Configure > Alerts.

  • Software Alerts

Checking this option will enable the Meraki cloud to send a nightly email to the network administrators listed in the “Delivery Settings” section regarding Systems Manager clients that have software installed matching the listed regular expression*.

*The expression field must be a valid POSIX regular expression, and the search is performed case insensitive. For example, if you want to receive a complete list of all software installed in the last day, you would enter ".*" (without quotes). If instead you wanted to be alerted when Starcraft or Warcraft is installed, you would enter "starcraft|warcraft" (without quotes).

  • Connectivity Alerts

Checking this option will enable the Meraki cloud to send an email* whenever a client endpoint with a specific tag stops checking-in for more than the determined time threshold. This will alert an administrator of any abnormal client outage.

*You will also receive an email when the client comes back online.
Client tags can be set by clicking on a client from the Monitor > Clients tab, clicking edit, and then editing the tags field. Please see Tagging Devices for more information.

  • Geofencing Alerts

This section gives you the option to enable the Meraki cloud to send an e-mail whenever a client endpoint violates a geofencing policy. You can also check the option to have an e-mail sent when a client re-enters their geofencing region after violating a geofencing policy.

  • Enrollment Alerts

Checking this option will enable the Meraki cloud to send an email when a client endpoint enrolls in a network. This will alert an administrator when an endpoint is added to a network.

  • Mobile Endpoint Management

If a client endpoint managed by Systems Manager has its Meraki Management profile removed, checking this option will allow the MCC to send an email to the network administrators listed in the “Delivery Settings” section.

It is very important to ensure that your managed endpoints retain the Meraki management profile, as this is the way your client endpoint checks in to the Meraki cloud.

For iOS endpoints, there is currently no way to password-protect the management profile from being deleted. From the end user perspective, removing the management profile will result in the possible loss of wireless connectivity, apps, and any enhancements gained from being managed by a Systems Manager network.

  • APNS certificate expires in X days.

When enabled, Systems Manager will send a daily email alert if the Apple Push Notification Service certificate expires within the set time threshold. The maximum threshold is 90 days and the minimum is 1 day.

Systems manager Endpoint Management alert settings under Network-wide > Configure > Alerts 


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.  

Camera alert setting under Network-wide > Configure > Alerts

Motion Alerts

Motion events get triggered when a portion of an area in the MV's field of view is changed, causing motion to be detected. When this occurs, an alert will be generated which will be directly sent to the configured email address. An example of what the email alert looks like is shown below:


Screenshot 2023-11-28 at 16.03.png

 

By default, your motion alert email will include a motion recap image that corresponds to the relevant event. More on Motion Recap here. However, if you have Restricted Bandwidth Mode enabled, you will not see an image.

If you are unable to see a Motion Recap image and you do not have Restricted Bandwidth Mode enabled, it is likely that SSL inspection is utilized upstream of a Meraki security camera. If so, please disable this to ensure you can view Motion Recap images.

Configuring Motion Alerts

  1. Navigate to Cameras > Monitor > Cameras
  2. Select a node from the camera list page
  3. 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.

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

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

Syslog, API, and SNMP each have their own benefits for network and device reporting.  Below is a list comparing each option with their possible use-cases.

Network Event Information Syslog API / Webhooks SNMP

Device Flows 

X    
Client Connectivity   X X
Configuration Changes    X X
Real-time information gathering X X X
Real-time network statistics X X X
Device information gathering X X X
Detailed device statistics   X X
Network-wide information gathering X X X
Organization-wide information gathering   X X
Proactive alerts for critical events   X X
Automation capabilities   X X
Application integration   X  
Cloud-centric    X  
Scalability   X  

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. 

  • Was this article helpful?