What Good IT Documentation Looks Like: The Runbooks That Save Time During an Outage

The server is down, the one person who set it up is on a plane, and everyone is trying to remember which switch connects to what. That is the moment documentation either pays for itself or doesn't. A good runbook lets another qualified person take clear, approved steps without rebuilding the whole picture from memory.

Start From the Questions the Business Will Ask

When something breaks, people want to know:

• What is affected?
• Who owns the system, and who can make the call?
• What depends on it?
• What is the safest next step?
• How will we know it's working again?
• Who needs an update?

A spreadsheet of serial numbers can be perfectly accurate and still be no help at 7 a.m. on a Monday.

The Core Runbooks Most Offices Need

Internet Outage

Write down the provider, circuit details, support numbers, network equipment, and your failover method. Add the quick checks that tell you whether it's the ISP or something inside your own network. Bell or Rogers will ask you for the account and circuit details before they do anything, so have them ready.

Microsoft 365 or Email Disruption

Cover tenant contacts, how admin access works, where to check service health, which channel staff should use while email is down, and who to escalate to for sign-in or mail-flow problems.

Server or Business Application Failure

Name the service owner and what the service depends on. Give the safe restart order, the vendor's support route, where this system sits in your recovery priorities, and how you'll test it with users and connected systems afterwards.

Cybersecurity Incident

Spell out first-hour roles, who has authority to contain, how to handle evidence, and the contacts for your insurer and any security specialist. See our first-hour response plan for a starting layout.

Backup Restore

Record what is backed up, where the recovery credentials live, who can authorize a restore, and how restored data gets checked before people start using it.

Employee Departure

Cover how to disable access, keep business records, hand over ownership of files and mailboxes, collect equipment, revoke sessions, and tell the right people.

What Every Runbook Should Contain

Use the same layout every time, so nobody has to learn a new format in the middle of an outage:

1. Purpose and trigger: when this runbook applies
2. Owner and alternate: who leads
3. Prerequisites: access, tools, approvals, dependencies
4. Steps: short and in order
5. Decision points: when to stop, escalate, or take another path
6. Validation: how you confirm recovery
7. Communications: who gets updates and when
8. Rollback: how to back out a change that went wrong
9. Review record: owner, date, change history

Keep passwords and recovery secrets out of the runbook itself. Point to the approved secure location, such as your password manager, instead.

Keep Diagrams and Inventories Alongside

A runbook works best next to a current network diagram, inventories of devices, software and services, vendor and support contacts, a list of who owns each admin account, dependency maps, and your recovery priorities.

Use the same system names everywhere. If the file server is "FS01" in one document and "the Dell" in another, a stressed responder will lose time matching them up.

Test the Instructions

Ask someone qualified who didn't write the runbook to follow it in a controlled exercise. Watch for unclear wording, missing access, screenshots from two versions ago, and steps that quietly assume knowledge nobody wrote down.

Update the documentation after a significant system change, an incident or recovery test, a change of vendor or contact, and any change in who owns what.

Documentation can't remove the stress of an outage, but it takes away much of the hesitation, especially when the usual expert isn't reachable.

Related Reading

This builds on our network-baseline monitoring guide. A baseline helps you see what changed. A current runbook tells people what to do about it.