CliDeck
PlatformLog in
Workspace

MikroTik RouterOS Safe Mode: Keep Remote Changes Small and Recoverable

Runbooks
#mikrotik-routeros#operational-evidence#runbooks#remote-operations#Runbooks
← Back to Blog

Short answer

Enter RouterOS Safe Mode before a small approved configuration change, confirm that the terminal shows <SAFE>, and keep the owning session open while testing. Release Safe Mode only after the acceptance checks pass. If the owning session fails, eligible changes can be undone; this protection depends on the undo history and is not a substitute for an independent console.

Scope and preparation

This runbook uses the RouterOS 7 interactive CLI workflow. Record the installed build and the actual terminal client before the window. Safe Mode controls configuration actions recorded for undo; keep firmware upgrades, resets, and reboot-dependent recovery in separate procedures.

Define one change, one management test, and one service test. Have an approved configuration backup and an independent access path. An operator watching the recovery path should know which terminal owns Safe Mode and when to escalate.

Coordinate all writers. Changes from other login sessions during Safe Mode can also enter the protected action history. Pause competing automation and tell other administrators about the window so an unrelated edit is not silently rolled back with yours.

Before changing configuration, inspect the existing action history:

/system/history/print

Keep the output private. Review the context of prior actions rather than interpreting every existing history entry as part of the new task.

Take Safe Mode deliberately

Press Ctrl+X in the interactive RouterOS terminal. F4 is another supported shortcut where the client delivers it correctly. These are keystrokes, not text commands to put into a pasted CLI script.

Confirm the Safe Mode taken message and the <SAFE> prompt indicator. If the browser, terminal client, or operating system intercepts the shortcut, do not continue until the device confirms the state.

If another operator already owns Safe Mode, coordinate with that person. Do not choose a takeover option merely to make an unfamiliar prompt disappear: takeover can preserve or undo another session's work.

Apply only the reviewed change lines. Separate state inspection, change commands, service testing, and release into distinct runbook steps. An unattended paste that enters and immediately releases Safe Mode removes the useful decision point.

Inspect the history while the test is active:

/system/history/print

The F flag identifies floating-undo actions. Check the expected actions and the current prompt state, then test a new authenticated connection and the affected endpoint. An already open terminal is not enough evidence that future logins or forwarding still work.

Verification note: the history limit changes the recovery promise

The current undo history retains up to 100 recent actions. If Safe Mode produces more actions than history can hold, RouterOS can leave Safe Mode and stop providing automatic undo for that session. A large import is therefore a poor fit for this protection.

Keep the change small and inspect the indicator after each logical step. If <SAFE> disappears unexpectedly, stop. Determine the current configuration through the independent path before deciding whether further edits are appropriate.

DecisionEvidence required
Continue testingOwning session remains in Safe Mode
Accept the changeFresh login and affected service pass
Stop and recoverUnexpected actions or lost protection

Accept or undo without confusing the exit paths

After successful testing, press Ctrl+X again in the owning terminal to release Safe Mode and retain the changes. Record the release message and verify the final configuration and service state.

For an intentional undo through the CLI, Ctrl+D exits and undoes Safe Mode changes. /quit does not perform that same undo. Do not use a generic logout command as evidence that rollback occurred.

An abnormal disconnect can take time to be recognized. The terminal workflow describes a TCP timeout of nine minutes for a lost Telnet or WinBox terminal connection; do not promise an instant rollback or use that interval as an exact guarantee for every client and transport. Watch actual recovery through the independent path.

After undo, test the original baseline again. If access stays unavailable, investigate the device and connection rather than repeatedly starting new changes.

Store the owning session, approved actions, history state, acceptance results, and final release or undo outcome. CliDeck Workspace can organize the remote-change preparation record and the subsequent handoff.

Who this is for

This guide is for operations teams, incident responders, network engineers, and system administrators who need to prepare, run, verify, and document operational terminal work on SSH, serial, browser terminal, and infrastructure operations workflows.

When to use this

Use this guide when:

  • Several commands or checks must be repeated safely.
  • Another engineer, customer, onsite technician, or vendor may need context.
  • The work should produce notes, logs, verification, or a clear handoff.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

Workflow

  • Define the purpose, target device, access path, and approved scope.
  • Run read-only checks first and record the expected healthy state.
  • Execute commands from the runbook or handoff plan while watching for stop conditions.
  • Verify the final state with independent checks.
  • Summarize commands run, outputs reviewed, exceptions, and handoff notes.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace is designed for this kind of operational workflow. Teams can keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace instead of spreading work across terminal windows, chat messages, screenshots, and separate documents.

CliDeck runbooks can be plain command lists, one command per line. Operators can send commands with one click or use auto-run behavior that waits for the prompt before sending the next line where configured.

FAQ

Does a runbook need to be code?

No. A useful runbook can be a plain list of commands, checks, notes, expected output, stop conditions, and verification steps.

Why use a browser workspace for terminal work?

A browser workspace can keep terminals, notes, runbooks, logs, and shared sessions together, which helps during incidents, handoffs, maintenance windows, and remote support.

Can shared terminal sessions be safer than screen sharing?

Yes, when implemented with clear view/type permissions. The helper can see the relevant terminal context without taking over the operator’s entire desktop.

Can CliDeck help with this workflow?

Yes. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful when the workflow starts at a rack-side console port.

Related guides