Change & Release Log

What this tool does

CM8-121 is a working change and release register. You record each change to your IT systems before it happens — what is changing, how risky it is, who asked for it and who approved it — then record the outcome afterwards. The tool works out your change success rate, watches the share of changes that arrive as emergencies, and flags the paperwork gaps that matter: high-risk changes with no written rollback plan, and implemented changes still waiting for their post-implementation review.

Everything runs inside this single file. There is no account, no upload and no network request of any kind, so system names, weaknesses and outage windows never leave the computer you are using — which matters, because a change register is also a map of where your infrastructure is fragile.

What counts as a change

Log anything that alters a production system or service: patches and updates, configuration changes, hardware swaps, migrations, new firewall or filtering rules, certificate renewals, releases of your own software. If it could break something a user relies on, it belongs in the register.

The discipline that makes the register worth keeping is simple: write the entry before the change, not after. An entry written beforehand records what you intended, who agreed to it and how you planned to get back — which is exactly the evidence you need when something goes wrong. An entry written afterwards is a diary. Changes that never get logged at all are the real danger: this register can only be as honest as the habit behind it.

Standard, normal, emergency

The three types most change frameworks share, and the ones this tool uses:

• Standard — routine, low-risk, done many times before, pre-approved as a category. Monthly patching of a well-behaved fleet is the classic example. Log each occurrence, but the approval is the standing one.
• Normal — assessed and approved case by case, with a scheduled date. Most meaningful changes are normal changes.
• Emergency — expedited because service is down, degraded or exposed and waiting for the normal process would cost more than the risk of moving fast. Approval is often retrospective; record who ratified it in “Approved by”.

Resist the temptation to reclassify things to make the numbers look better. An emergency logged as normal hides exactly the signal — how often you are forced to skip your own process — that the emergency share exists to show.

Risk and approval

The risk field asks one practical question: how bad is it if this goes wrong, and how hard is it to get back? A change with a small blast radius and an easy reversal is low. A change that touches many users, or that cannot easily be undone — schema migrations, storage work, core network changes — is high, even if you are confident it will succeed. Confidence is not low risk; reversibility is.

Approval in this tool is deliberately blunt: the change is approved when somebody's name is in “Approved by”, and unapproved when the field is blank. The register marks an unapproved change that has moved past draft, and marks it strongly when the risk is high — an unapproved high-risk change on a future date is the single most useful warning this tool can give you. The exceptions table also lists any non-draft change with no approver recorded.

Rollback plans

A rollback plan is the written answer to “and if it doesn't work?” — the snapshot to restore, the old unit kept on the shelf, the previous package version, the config export, and how long any of them will take. Tick “rollback plan documented” only when that answer is actually written down somewhere you could follow at two in the morning; keep the evidence, or a pointer to it, in the notes.

The tool counts high-risk changes without a documented rollback plan as a headline figure and lists them in the exceptions table, because that combination — hard to reverse and no written way back — is where change management earns its keep. The tile counts every non-cancelled change, whatever its status: a high-risk change already implemented without a rollback plan is a lesson to record, not a number to hide.

Outcomes and the success rate

When the work is done, set the status to implemented if the change achieved what it set out to do and stayed in, or failed — rolled back if it had to be reversed. Record the implementation date either way; the tool will ask for it.

The denominator is only the changes that actually reached a conclusion. Draft, approved, scheduled and cancelled changes are excluded — they have no outcome yet, and counting them would flatter or damage the figure for no reason. Until at least one change has completed, the tile shows “—” rather than a meaningless number. The failure-rate chart applies the same rule month by month, and only plots months that contain at least one completed change.

With a handful of changes a month, one rollback swings the monthly figure enormously. That is arithmetic, not a crisis: read the trend across several months, and read the notes on the failures — a rollback executed cleanly from a documented plan is the process working.

The emergency share

The proportion of your changes that arrive as emergencies is one of the best single indicators of how much control you actually have. A low share means most work is planned, assessed and scheduled; a rising share means the process is being overtaken by events — or quietly bypassed.

The basis excludes drafts, which are not yet real commitments, and cancellations, which never happened. Everything else — approved, scheduled, implemented and rolled back — counts, whichever type it is. Set the ceiling you are prepared to accept on the Settings tab (10 % by default) and the tile shows the share against it, always stating the counts behind the percentage.

Post-implementation reviews

A post-implementation review is a short, honest look back after a change has bedded in: did it do what the request said, did anything break that was not predicted, was the outage window respected, and would you run it the same way again. For a routine standard change it is not worth the meeting; for anything risky it is where the organisation actually learns.

Choose on the Settings tab whether a PIR is expected at medium risk and above or at high risk only. The tool then counts implemented changes at or above that level with the review box still unticked, shows the count as a tile, and lists each one in the exceptions table until the review is recorded. Rolled-back changes deserve a review too — the tool does not count them in this figure, because its definition is deliberately narrow, but the failure notes should say what the review found.

Outage minutes

Tick “outage required” for any change that interrupts service, and record the length in minutes — planned length beforehand, actual length afterwards. Leave the minutes blank if there was no outage or nobody measured it: a blank is honest, a guess is not. Any total of outage minutes you compute from an export covers only the rows where a figure was recorded, and should say so.

Printing and sharing

Print Report produces a report from whatever the current filter shows: header, the headline tiles, the four charts, the upcoming schedule, the exceptions list, the full register and your closing notes. Print to PDF to circulate it — it reads well as the standing paper for a change advisory meeting, or as evidence of change control for an auditor or an insurer.

The scope line under the title states the filter in force. Clear the filters before issuing anything described as the full period, and remember that a filtered success rate describes only the filtered changes.

Saving your work

Changes, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work and includes every filtered record, not only those drawn on screen. Reset asks twice, then erases everything this tool has stored. There is no undo.

Accuracy & disclaimer

This tool records what you enter and calculates from it. It cannot tell whether a change was classified or risk-rated honestly, whether the rollback plan would actually work, or whether changes are being made without being logged — and every figure on the page depends on all three.

Change-management obligations differ by industry and by contract: regulated sectors, customer agreements and certification schemes may each demand specific approval steps, records and retention periods. This is an internal record-keeping and calculation aid, not a compliance system and not a substitute for whatever process your obligations require.