¶ KBA-023 - Meraki Safe and Unsafe Configurations
Summary: Meraki devices maintain a checkpoint called the "safe configuration" — the last configuration received from the cloud under which the device remained connected and did not reboot for 30 minutes. If a subsequent configuration change leaves the device in a state where it cannot reach the Meraki cloud, the device reverts automatically to this safe configuration. This mechanism acts as a self-healing safety net against misconfiguration.
¶ How Safe and Unsafe Configurations Are Defined
Meraki uses a simple, time-based rule to determine whether a configuration is safe:
A configuration is considered safe when the device has maintained connectivity to the Meraki cloud and has not rebooted for 30 continuous minutes following the configuration change. Once both conditions are met, the new configuration is promoted to the safe configuration checkpoint and replaces the previous one.
A configuration is considered unsafe if either of the following is true at any point within that 30-minute window:
- The device loses connectivity to the Meraki cloud
- The device reboots
If the device later determines that connectivity cannot be restored, it discards the unsafe configuration and reverts to the previous safe one.
⚠️ The 30-Minute Window Applies to Every Change
Every time a new configuration is pushed from the dashboard, the 30-minute clock restarts. The currently active configuration remains unsafe until the full window has elapsed with unbroken cloud connectivity. If a firmware upgrade triggers a reboot, the post-upgrade configuration is also considered unsafe until the timer completes — or 2 hours on MS switches.
The conditions that trigger a revert to safe configuration are consistent across device types, but the exact revert mechanism and timing differ:
- With a safe configuration and sustained cloud disconnection, the MX behaviour depends on firmware:
- Firmware below 14.53 / 15.11: reboots after 4 hours of cloud disconnection
- Firmware 14.53 to 17: no reboot
- Firmware 17 and above: reboots after 8 hours (self-healing support)
- With an unsafe configuration: reverts immediately to the previous safe configuration
The MS has the most distinct behaviour of any Meraki device type in this regard:
- With a safe configuration: never reboots due to cloud disconnection
- With an unsafe configuration:
- First attempts IP acquisition on an alternate VLAN to try to restore cloud connectivity
- If connectivity is not restored within 2 hours, reverts to the previous safe configuration
- Marks the reverted-from configuration as bad
The 2-hour window (not 30 minutes) is specific to the MS revert timer. The 30-minute rule still defines when a configuration becomes safe in the first place — the 2 hours is the maximum time the switch will persist with an unsafe config before giving up.
- With a safe configuration: behaviour depends on SSID mode
- All SSIDs in NAT mode with a failed gateway ARP test: reboots every 4 hours
- At least one SSID not in NAT mode: no automatic reboot
- Wi-Fi 6 / 6E firmware 28.1 and above: additional reboot trigger after 8 hours without dashboard communication
- With an unsafe configuration: reverts to the previous safe configuration
- With a safe configuration:
- MG21 (firmware 1.11 and above): modem and platform reset every 1 hour
- MG41 / MG51 / MG52 (firmware 2.0 and above): platform reset every 30 minutes
- MG41 / MG51 / MG52 with standby SIM: SIM failover after 5 minutes
- With an unsafe configuration: reverts to the previous safe configuration
The most common real-world scenarios that leave a device with an unsafe configuration are:
- Management VLAN change — if the VLAN used for cloud communication is changed and the device cannot reach the cloud on the new VLAN, the 30-minute timer never completes
- Uplink or IP address change — changes to WAN interface settings on an MX that prevent the uplink from establishing
- Firewall rule blocking cloud — an ACL or firewall rule that inadvertently blocks the device's outbound connections to the Meraki cloud (
*.meraki.com, TCP 443 / UDP 7351)
- Firmware upgrade reboot — the post-upgrade configuration is unsafe until the device reconnects and holds connectivity for 30 minutes (or 2 hours on MS)
- Power loss or unexpected reboot — any reboot during the 30-minute window leaves the configuration unsafe
When a device reverts to a safe configuration, the Meraki dashboard will reflect this in several ways:
- The device status will show as Out of date — the active running configuration no longer matches what the dashboard has pushed
- Change log entries may indicate a revert event
- Alert notifications can be configured to fire on device connectivity loss, which often precedes or accompanies a safe config revert
If you see a device persistently showing as out of date after a configuration change, the most likely explanation is that the change caused the device to lose cloud connectivity before the safe configuration timer completed.
- Staged rollouts — when making changes that affect cloud connectivity (management VLAN, firewall rules, uplink configuration), consider staging to one device first and confirming it remains online for 30 minutes before rolling out to the rest
- No manual rollback in the dashboard — there is no native configuration rollback button in the Meraki dashboard. If a change needs to be undone, it must be reversed manually via the dashboard change log (
Organization → Change Log) or by correcting the configuration directly
- Firmware upgrades — after a firmware upgrade, a device is in an unsafe state until it has been online for the full timer period. Avoid making further configuration changes until this window has elapsed
- Console access — if a Meraki device reverts to a safe configuration, the revert is automatic and does not require console access or manual intervention. However, if the device reverts and connectivity is still not restored, physical access may be needed