It is 02:40. The maintenance window is closing, the switches are back online, and someone types the inevitable question into the chat: "Everything okay?" You look at a ping, run a quick show command on the core, and answer the only thing you can: "Looks good."
Three days later the phone rings. A duplex mismatch has been quietly eating a floor's throughput since the window, and nobody can say whether it was there before. That is the real problem with "looks good": not that it is wrong, but that it cannot be checked. The fix is not more attention at 02:40. It is a baseline, the same checks on every run, and a diff.
Baseline While Everything Works
You cannot prove that nothing changed without a record of how it looked before. Capture a per-switch baseline on a healthy, boring day, not in the middle of an incident. That baseline becomes the reference every later run is measured against, and the honest answer to "was that always like this?"
Save the current health check results as the switch's baseline in one click, and update it when the approved state legitimately changes.
Run the Same Checks Every Time
If every engineer runs their own favourite show commands, no two runs are comparable. The value is not in any single command, it is in asking the network exactly the same questions every time. A curated command set makes results comparable across switches, across engineers, and across months.
Admins maintain the health check command set centrally, so every run asks the same questions and the answers line up.
Parse the Output, Do Not Eyeball It
A wall of raw CLI text hides small changes, and small changes are exactly what you are looking for. Structured parsing turns command output into fields that can be compared automatically, so a changed value stands out on its own instead of hiding in line 400 of a terminal scrollback.
Health check output is parsed into structured results using TextFSM templates, so comparisons happen on values, not on screenfuls of text.
Diff the After Against the Before
Re-run the same checks as the last action inside the maintenance window, while you can still fix what you find, not the next morning. Then compare against the baseline and read the diff: what changed, and on which switch. If the diff is clean, you are done. If it is not, you know exactly where to look while the change is still fresh.
Pro tip: Make the diff the exit criterion of the window. The change is done when the diff is clean, not when the uptime counter starts moving.
Every run is compared against the switch's baseline and summarised as a readable diff, with per-switch labels so a fleet-wide run can be scanned at a glance.
Keep the History, Gate the Risky Steps
Evidence only helps if it is still there next quarter. Keep labelled runs with notes, compare any two runs later, and let the history answer "when did this start?" instead of your memory. And for the riskiest step of all, activating a new IOS-XE image, do not rely on discipline alone: make a recent baseline a requirement, not a habit.
Runs are stored with labels and engineer notes, any two runs can be compared, and install-mode upgrades refuse to activate when there is no recent health check baseline for the switch.
The Bottom Line
"Looks good" is a feeling. A clean diff is a fact. Baseline while everything is healthy, ask the same questions on every run, parse instead of eyeball, diff before you leave the window, and keep the history where the next person can find it.
Do that, and the next 02:40 "everything okay?" gets a different answer: not a guess, but a one-line reply with evidence behind it.