A rollback plan is not tested merely because a backup exists. A useful test proves that you can identify the last known-good workflow, stop future and active runs safely, restore the intended definition, and resume on schedule without repeating completed work. Run the drill against a non-production target or a deliberately harmless task first.
Define the rollback point before changing anything
Record the workflow version, schedule, time zone, permissions, inputs, secrets references, destination, and the identifier used to prevent duplicate work. Export or otherwise preserve the current definition in the platform's supported format. On Windows Task Scheduler, the ScheduledTasks module includes commands to export, register, disable, enable, start, and stop tasks. GitHub Actions provides controls for manual runs, cancellation, reruns, and disabling or enabling workflows. Those controls are the ingredients of a rollback, but your record must say which one to use and in what order.
Choose a visible success signal, such as one test file, one log entry with a run ID, or one message delivered to a sandbox. Also choose a failure signal and a maximum wait time. Do not use a production payment, deletion, or customer notification as the test payload.
Rehearse a controlled failure
Change only one reversible detail: point the job at a sandbox destination, use an invalid test input, or temporarily replace the action with a harmless command that exits unsuccessfully. Trigger one run manually when the platform supports it, or use a short temporary schedule in the test environment. Confirm that monitoring identifies the failed run and that the operator can find the exact definition and run ID involved.
Next, exercise the stop step. Disable future triggers before restoring the definition. If a run is still active, cancel or stop it and note whether the platform finishes an in-progress step. Disabling a schedule and stopping an active run are separate actions; a good runbook names both.
Restore and verify the known-good state
Restore the saved definition using the platform's normal import, registration, or version-control path. Review the schedule and time zone before re-enabling it. Run the restored workflow once against the safe target and confirm the success signal. Then check that the next scheduled time is correct and that exactly one output exists for the test run.
A passing rollback drill should answer five questions with evidence: Which version was restored? Who performed the rollback? Which run was stopped? What proved the restored workflow worked? What prevented a duplicate? Save screenshots or logs with timestamps, but do not copy secrets into the record.
Close the gaps the drill exposes
If the operator had to guess, update the runbook. Common gaps include an unexported schedule, a missing time-zone note, no safe test destination, credentials that belong to one person, and no idempotency key or duplicate check. Repeat the drill after corrections. A rollback is ready only when another authorized operator can follow the written steps and reproduce the same safe result.
Sources
- Managing workflow runs — GitHub Docs
- ScheduledTasks Module — Microsoft Learn
- Register-ScheduledTask — Microsoft Learn