Cutover Timeline Builder: Turn a Step List into Timed Runbook Rows
A cutover timeline builder converts a list of steps and durations into clock times. Enter the start of the cutover window and one step per line with its duration in minutes; the tool returns the start and end time of every step, the running elapsed time, the total, and where the sequence crosses the window end if you supply one.
What the builder does
It takes a start date and time, a list of steps with durations, and turns them into a sequence with a clock against every row. Each step starts when the previous one ends. If a window end is supplied, every row is marked as inside or past the window, and the first step that ends after the close is named. The arithmetic is trivial; doing it by hand at eleven at night is where it goes wrong.
Durations go at the end of the line, separated by a comma, a semicolon, a pipe or a space. "Database backup, 60" works. So does "Database backup | 60 mins". Lines without a number at the end are skipped and counted, so a heading left in the paste is reported rather than silently dropped.
Serial time is not the same as the plan
The output is a strictly serial sequence: one step after another, nothing overlapping, no contingency. Real cutovers run some steps in parallel, hold gates between phases and carry buffer. Two ways to use that gap deliberately. Model the parallel branch as a single line with the duration of its longest step. And add explicit buffer lines — "contingency, 60" — rather than padding individual steps, because padded steps hide where the slack went.
A serial total is still the number worth having early. If the serial run already exceeds the window before contingency, parallelism is not an optimisation, it is a dependency. The cutover plan guide covers the sections around the timeline, and cutover plan vs cutover runbook covers where a timed sequence like this belongs.
What a runbook adds
A timeline is one column of a runbook. The rest is the part that runs the night: owner per step, the deputy when the owner is asleep, the command or script reference, the verification that proves the step worked, the predecessor, and a status column somebody updates live. The cutover runbook workbook holds those columns across the weekend and the hypercare period after it, and the rollback plan template keeps the reverse sequence timed against the same window, including the point of no return.
Privacy
Everything is computed in the browser. Step names are never sent anywhere and nothing is saved. Copy the table out before you close the tab.
Questions
What format do the step lines need?
Step name first, duration in minutes last, separated by a comma, semicolon, pipe or space. "Data load and transform, 120" is read as a 120-minute step. Lines with no trailing number are skipped and counted.
Does it handle steps running in parallel?
No. The sequence is strictly serial. Model a parallel branch as one line carrying the duration of its longest step, and note the branch detail in the runbook itself.
Should contingency be built into each step?
The tool takes whatever durations it is given. Adding contingency as its own line keeps it visible; padding individual steps hides how much buffer the plan actually holds.
Does the timeline cross midnight correctly?
Yes. Times run on real dates, so a window starting at 20:00 on Friday and running eleven hours ends on Saturday morning, with the day shown in each row.
Is anything saved between visits?
No. There is no storage, no account and no network call. Closing the tab clears the steps.