Write the change record for the person who reads it at 2am.

The audience is the person recovering, not the person approving

A change record can be written primarily to secure approval and still omit information needed during recovery. The moment they matter is later, when something is behaving oddly and somebody needs to know precisely what altered and how to put it back.

Writing for that reader changes what goes in. Keep the purpose and impact, then add the exact actions, the configuration before the change and the specific signal that says it worked.

Record the previous state, not only the new one

A record that describes the target configuration without capturing what was there before is not a rollback plan. Export the current settings, note the version, keep the old file, and reference where it is stored.

If the rollback needs a maintenance window of its own, say so in the record. Discovering that during an incident is expensive.

State how you will know it worked

Name the check: the query you will run, the page you will load, the user who will confirm. “Monitor for issues” is not a verification step and it puts the burden on whoever is on call afterwards.

Include the timeframe too. Some changes fail on the next scheduled job, not on implementation, and the record should say when it is safe to stop watching.

Keep it short enough that it gets written

A template nobody can complete under time pressure produces empty fields and a false sense of governance. Cut the record down to what a colleague genuinely needs, and it will be filled in properly.

Describe the failure signal before the window

For a fictional application configuration change, write the current version and where its protected backup is stored. Define the check that matters to users, such as completing an approved test transaction and confirming it appears in the downstream system. Decide who observes it and who can call for rollback.

A threshold could be a failed test or an agreed period without successful processing. Choose it for the service and record the decision before starting. “We will decide if it looks bad” leaves the operator negotiating criteria while the window is closing.

Be precise about what rollback can recover

Restoring an old configuration is not necessarily enough after data has changed. A database migration, external message or deleted record may require a separate recovery or correction process. Record those limits and seek the appropriate decision before implementation.

Close the change with the actual times, versions, checks performed and outstanding observations. If a later scheduled job still needs checking, assign that follow-up explicitly. The person taking over should be able to tell what is confirmed and what remains an expectation.