What to Put in a Change Ticket Before a Switch Reboot

"Reload the switch" is five seconds of typing and five minutes of downtime — unless the config wasn't saved, the second uplink wasn't actually redundant, and the change ticket said "routine maintenance." Reboots without real change tickets are the ones that take the floor down. This is the field set that gets a reboot approved in one pass instead of bounced with questions.

The five fields a reboot ticket must answer

• Scope — the exact device. Hostname, rack/U, serial. If it is a stack, say so and name every member being reloaded (whole-stack reload vs one member is a completely different change).
• Blast radius — what drops and what covers it. List every device, port, and customer-facing link that goes down during the reload, and the redundancy that covers each: HSRP/VRRP pairs, MLAG/LACP members, redundant PSUs, the second path in the ring. "No impact" is a claim — back it with the specific redundant path.
• Reason and expected outcome. Why the reboot is needed (firmware upgrade, config change requiring reload, stuck process) and what success looks like after (all ports up, OSPF/BGP neighbors re-established, error counters clean).
• Window. Date, start/end time with timezone, and who authorized it. If approvals are needed from a customer or a change board, name them — don't file the ticket with "TBD."
• Verification plan. The exact post-reload checks you will run: console reachable, all expected ports up, routing neighbors up, no new interface errors, spot-check of the affected devices.

Before anyone approves: the pre-reload checks

1. Saved config matches running config. This is the one that kills reboots. Verify the startup config equals the running config — record the output or both checksums in the ticket. A reload with an unsaved config brings back yesterday's interfaces, VLANs, and port-channels.
2. Firmware/version noted. Record the current version and the target version if this is an upgrade. Know where the fallback image lives.
3. Console access verified. Confirm working console/OOB access before the reload. If the switch comes back wrong and you have no console, you are dispatching hands to the rack.
4. Redundancy is real, not assumed. Verify the redundant path is actually carrying traffic right now (check the standby is up, the LACP member is active, the failover pair is synced) — not just cabled.
5. Stakeholders notified. NOC, affected customers, the shift lead. Notification timestamps go in the ticket.
6. Rollback plan with an owner and a time box. What counts as failure (e.g., ports not up in 15 minutes, neighbors not re-established in 20), who decides to roll back, and what rollback means (restore config from the ticket attachment, revert firmware, or escalate to vendor TAC with the case number pre-opened).

A change note that gets approved in one pass

Change: reload sw-c12-04 (rack C12 U18, SN XXXXXXX) for firmware 15.2(7)E10 → 17.9.5.
Blast radius: ports 1/1/1-24 drop for ~8 min; covered by HSRP pair sw-c12-05
(verified active 13:30) and dual-homed uplinks to core (LACP members active).
Window: 2026-10-20 02:00–03:00 UTC, approved by change board #CB-2214.
Pre-checks: running == startup config verified (checksums match); console/OOB
reachable; fallback image in flash; TAC case #XXXX opened.
Verify after: all 48 ports up, OSPF neighbors 4/4, no CRC increments 10 min.
Rollback: if ports/neighbors not healthy by 02:30, restore prior config from
attached backup and boot previous image; owner: on-shift lead.
Ask: approve reload in the window above.

The mistakes that get reboot changes rejected

• "Routine maintenance" as the reason. Change boards cannot approve a blank. State the exact reason and the expected outcome.
• Unsaved config. The number-one cause of a reload turning into an outage. Verify and record running-vs-startup before anyone approves.
• Assumed redundancy. "It has two uplinks" is not a check. Verify the second path is active right now, or the ticket gets bounced.
• No rollback. A change without a rollback plan is a gamble filed as paperwork. Name the failure condition, the owner, and the time box.
• Missing timezone on the window. 02:00–03:00 means nothing without UTC/local. One timezone mixup has caused more outages than bad hardware.

See RackReady   Free sample   Ticket note examples

Support: support@hasherventures.com

Free tool: turn your checks into a structured ticket note with the RackReady Ticket Builder.