A remote network change becomes an outage when the change breaks the only path back to the device. It does not matter whether the mistake is a bad ACL, an incorrect default route, an interface change, or an authentication policy that locks out your SSH session. If you have no console server, out-of-band path, or helpful person near the rack, you are now waiting for someone to drive there.

For many Cisco IOS and IOS XE changes, a scheduled reload is a cheap and powerful safety net. You arrange for the device to reboot from its known-good startup configuration unless you explicitly cancel the reload after testing the change. It is one of those old operational habits that remains useful precisely because it is simple.

The important distinction is this: a scheduled reload is not a rollback system. It reboots the device. It only returns you to safety when the startup configuration is known good and you have not saved the risky running configuration before validating it.

The Safe Pattern

Use this pattern for a remote change that could cut off management access:

1. Confirm that the current startup configuration is a usable baseline.
2. Schedule a reload with enough time to make and test the change.
3. Verify that the reload is actually pending.
4. Make the change in the running configuration, but do not save it yet.
5. Test from the perspective that matters, preferably through an independent management path.
6. Save the working configuration, cancel the scheduled reload, and verify that it is gone.

The commands below are privileged EXEC commands on platforms that support this syntax. Cisco command details vary by hardware and software release, so use reload ? and the command reference for the device in front of you before a production change.

router# show reload
router# reload in 15
router# show reload

Fifteen minutes is a reasonable default for a small, well-understood change. Make it longer when you need a maintenance window, a change review, a remote pair of hands, or time for routing convergence and monitoring to settle. The device will prompt for confirmation; read the scheduled time rather than reflexively pressing Enter.

show reload is not optional ceremony. It verifies both that a reload is scheduled and when it will happen. The Cisco reload command supports both an interval (reload in) and a wall-clock schedule (reload at), plus reload cancel to abort a pending reload. A wall-clock schedule relies on the device clock, so do not use it for coordinated work unless NTP and the configured time zone are trustworthy.

Start From a Known-Good Startup Configuration

The safety net works because a reload discards unsaved running-configuration changes. Before you schedule it, inspect the configuration state and make sure the saved configuration is intentionally the one you want to return to:

router# show running-config
router# show startup-config
router# show reload

If the startup configuration is stale, repair that problem before the risky change. Save the current good state, capture an off-device copy according to your team's configuration-management practice, and make sure the device is set to boot normally. A scheduled reload cannot rescue a device that lands in ROMMON or boots a broken image.

This is why blindly issuing write memory after every command is a bad habit during remote access changes. If you save a broken ACL, route, AAA policy, or VLAN configuration, the reload faithfully restores the broken configuration.

A Concrete SSH-Access Example

Suppose you are tightening management access. You want to change the VTY access list, but a typo in the source subnet or the line configuration could disconnect your session.

First, schedule and verify the escape hatch:

switch# reload in 15 remote-ssh-change-safety-net
switch# show reload

Then apply the candidate change. The exact ACL, authentication method, and VTY range are site-specific; do not paste this example into production unchanged.

switch# configure terminal
switch(config)# ip access-list standard MANAGEMENT-SOURCES
switch(config-std-nacl)# permit 192.0.2.0 0.0.0.255
switch(config-std-nacl)# exit
switch(config)# line vty 0 15
switch(config-line)# access-class MANAGEMENT-SOURCES in
switch(config-line)# transport input ssh
switch(config-line)# end

Do not test that change only in the session you used to make it. Open a second SSH session from an allowed management host. Confirm that it authenticates, that the expected commands work, and that a connection from a non-management network is denied. If possible, test through the ordinary management route and through the out-of-band path separately.

Once the result is good:

switch# copy running-config startup-config
switch# reload cancel
switch# show reload

The order matters. Save only after the functional test succeeds, then cancel the pending reload and confirm that show reload no longer reports one. For a fuller baseline on protecting remote access, see Securing Virtual Terminal (VTY) Lines.

When a Scheduled Reload Is the Right Tool

Scheduled reloads are particularly effective for changes that are easy to validate quickly and whose failure mode is loss of device reachability:

• management ACL, VRF, route, gateway, or interface-address changes;
• SSH, AAA, TACACS+, RADIUS, or local-login changes;
• VLAN trunking or switchport changes that may isolate the management VLAN;
• simple routing-policy edits where you can validate routes and reachability before the timer expires; and
• one-device maintenance where a reboot is an acceptable fallback.

They are less attractive for a chassis or stack with a long reboot and recovery time, a change that affects many devices at once, or an operation that cannot be cleanly tested in the timer window. In those cases, use the organization's normal maintenance process, out-of-band console, staged deployment, and platform-specific rollback capabilities.

Do Not Treat Rebooting as a General Undo Button

There are real limits to this technique.

First, it creates an outage if the timer expires. That may be preferable to an indefinite lockout, but it is still an outage. Tell stakeholders what will happen, choose a window with enough room to recover, and avoid using the timer as a substitute for a change plan.

Second, it does not reverse changes outside the configuration model. A software upgrade, boot-variable edit, failed hardware state, external firewall change, or a configuration already written to startup-config needs its own recovery plan. Likewise, a reload can be a poor rollback for stateful services or a device carrying traffic that cannot tolerate a reboot.

Third, command support varies. Cisco IOS XE also supports configuration archive and confirmed-rollback workflows on supported platforms. Those can return the configuration to a saved state without relying on a full reboot, but they need an archive design and model-specific validation. Use them when your platform and operational model support them; keep scheduled reloads as the simple, widely understood fallback.

Make the Test Real

The most common mistake is declaring victory because the existing SSH terminal is still open. That terminal proves only that an already-established TCP session survived. It does not prove that a new administrator can authenticate through the intended network path.

Use a second terminal, a second jump host, or a colleague on the other side of the policy boundary. Check DNS if names are part of the workflow, verify the expected source IP, and confirm the monitoring system can still reach the device. For an interface or routing change, test the actual destination and traffic class—not merely a ping to the device itself.

This habit belongs with other boring, high-value operating practices: observe before changing, keep a known-good baseline, and make the recovery path explicit. The same principle appears in Cisco load-interval 30: When to Use It and When to Leave It Alone: a useful operational knob becomes dangerous when you mistake a narrow signal for the whole system.

A Small Change Checklist

Before the change:

• Confirm console or out-of-band options and the on-call recovery path.
• Capture the device model, software release, current configuration, and startup-configuration state.
• Schedule the reload and confirm it with show reload.
• Decide exactly how you will test success from an independent path.

After the change:

• Test new authentication and reachability rather than trusting the original session.
• Inspect the intended running configuration and relevant logs.
• Save only after the change is demonstrably correct.
• Run reload cancel, then show reload again.
• Record the change and remove any temporary access you introduced for testing.

Scheduled reloads will not make every remote Cisco change safe. They do make a large class of otherwise stressful changes bounded: if your candidate configuration fails, the device returns to its known-good startup configuration on a timer. That is a far better ending than discovering a bad management ACL at 2 a.m. with no way back in.

For the exact reload syntax and platform constraints, consult Cisco's IOS reload command reference. Return to Slaptijack for more practical networking and systems articles.