Maintenance planning

What this covers

• The intended change and expected visible result.
• Pre-checks, post-checks, and the point where the work should stop.
• Rollback conditions that are clear before the window begins.

Plan the decision path

Maintenance planning is not only scheduling. It is a written decision path that says what changes, what gets checked, when to continue, and when to stop.

This matters most for small teams because the same person may be planning, making the change, and verifying the result. A clear note reduces the number of decisions made under pressure.

Separate the change from the verification

The change itself can be short: update a record, publish a page, rotate a certificate, or adjust a setting. The verification deserves its own section because it answers a different question.

A good verification list checks public behavior rather than only internal completion. If visitors should see a page, the page should be opened. If a name should resolve, it should be checked from a public resolver.

Define rollback before starting

Rollback conditions are easiest to write before the work begins. Once a window is active, it is tempting to keep trying one more fix.

A useful condition is visible and specific: a key path returns the wrong status, a certificate does not cover the active name, or the expected page does not load after a defined waiting period.

Planning checklist

• Describe the intended change in one or two sentences.
• Record the expected public result.
• Run and record the pre-check before changing anything.
• Define the rollback condition and decision owner.
• Run the post-check and close the note with the final state.