Start with the questions a stand-in would ask
A maintenance runbook is a short set of instructions for keeping a website working. Its purpose is not to describe every technical detail. It should help someone who knows the site, but has not handled its day-to-day upkeep, find the right accounts, complete routine tasks and respond calmly to a problem.
Begin by imagining that the usual maintainer is unavailable. Who can approve a change? Where is the site hosted? Which system publishes content? Who receives notices about billing, renewals or downtime? Write down the answers, including the names of services and the roles responsible for them. If one person fills several roles, record that too. It makes a gap in coverage easier to spot.
Keep the runbook somewhere the appropriate team members can reach even if the website itself is down. Give it an owner and a review date. A document no one can find, or one that describes a previous hosting setup, is unlikely to help when time matters.
Record how the site fits together
Make a compact inventory of the systems needed to operate the site: domain registration, DNS, hosting, content management system, email used for site notices, backup storage and any important forms or integrations. For each, note its purpose, the account owner or team, where administrative access begins and who can help if access fails. You do not need a network diagram to make this useful; a simple table in the runbook may be enough.
Document dependencies that are easy to overlook. For example, a contact form might send messages to a mailbox managed by someone outside the website team. A scheduled publishing task might depend on a particular account. These details help a stand-in understand why a feature can stop working even when the homepage loads.
Do not put passwords, recovery codes or other secrets in the runbook. Instead, identify the approved password manager or access process and state who is authorized to use it. Limit access to the runbook as appropriate, since even an account inventory can reveal how a site is managed.
Turn recurring work into short procedures
List maintenance tasks with an owner, a rough cadence and a clear completion check. Tasks might include reviewing available software updates, checking that backups completed, renewing paid services, testing important forms and removing access that is no longer needed. The cadence should fit the site and its tools; the useful part is making the work visible rather than relying on memory.
For each task, write only the steps a competent stand-in would need. An update procedure, for instance, might say where to check for changes, which environment to use for testing, what to verify afterward and where to record the result. Link or refer to a separate detailed procedure if one already exists, rather than copying instructions into multiple places that may drift apart.
Add a small change log: what changed, when, who made the change and whether anything needs follow-up. It can be a section of the runbook or a separate shared record. When an issue appears weeks later, a concise history can help the team decide what to check first.
Make the first response to trouble easy to follow
A runbook should not assume that every alert means the same thing. Give readers a safe starting sequence: confirm the reported problem, note its time and visible symptoms, check whether it affects one page or the whole site, and contact the person responsible for the relevant system. Include where to find monitoring notices and support contact details. Avoid instructions that encourage an unfamiliar person to make risky changes in haste.
Define who can authorize emergency work and how the team will communicate if normal website channels are unavailable. If the site may have been compromised, the runbook can direct the reader to the team’s incident procedure rather than trying to fit a full investigation into a quick-reference document.
Finally, ask someone other than the primary maintainer to use the runbook for a harmless task, such as locating the backup status or finding the hosting support contact. Note where they got stuck and revise the instructions. Repeat that check after major service or staffing changes. The best runbook is not the longest one; it is the one a colleague can actually use.
