Keep enough evidence to reconstruct the change without copying secrets or retaining every log forever. At minimum, preserve the approved reason, the exact before-and-after workflow definition, schedule and time zone, actor, change time, first run ID, result, and a sample output. The record should let another authorized operator answer what changed, what executed, and whether rollback is possible.
Capture the state before the change
Save the workflow version or export the supported task definition before editing it. Record the workflow name, owner, enabled state, trigger, schedule, time zone, input source, destination, and duplicate-prevention key. For a Windows scheduled task, capture the task path and last-run information; Microsoft documents Get-ScheduledTaskInfo as a way to obtain a task's last run-time information. For a version-controlled workflow, preserve the commit or revision identifier rather than pasting the entire file into an informal note.
Add the business reason, requested outcome, reviewer, planned test, and rollback point. If a credential reference changes, record the name or identifier of the reference, not the secret value. Note any retention period that could cause logs or artifacts to disappear before the review.
Tie the change to a specific run
After the edit, record the first run ID, attempt number, start and finish times, trigger source, status, and the revision that actually ran. GitHub Actions lets authorized users view, search, and download job logs; its run pages show whether the result was successful, failed, canceled, or neutral. GitHub also notes that logs from a partial rerun cover only the jobs rerun in that attempt, so retain the identifiers for earlier attempts when they are needed for a complete record.
Preserve a small output sample or artifact hash that proves the intended destination changed correctly. Do not treat a green status alone as proof: a workflow can complete while producing nothing, using stale input, or writing twice. Include counts, timestamps, or destination identifiers that can be checked independently.
Record the operational controls
Note whether the workflow was disabled, manually run, rerun, canceled, or re-enabled during the change. GitHub documents those controls for workflow runs. For other schedulers, capture the equivalent actions and the next expected run time. If the platform distinguishes disabling future triggers from stopping an active run, record both states separately.
Keep the first scheduled run after the change, not only a manual test. Compare its start time, input window, output count, and duplicate check with the baseline. If daylight-saving changes or business calendars matter, state which time zone and exception rules were used.
Close the record with a clear decision
Finish with one of three states: accepted, rolled back, or monitoring. An accepted change includes a passing test and a normal scheduled run. A rollback names the restored version and evidence from the restored run. Monitoring names the unresolved question, owner, and review time. Store the evidence where the next operator can access it, apply the normal retention policy, and redact tokens, personal data, and customer content that are not needed to explain the change.
Sources
- Using workflow run logs — GitHub Docs
- Managing workflow runs — GitHub Docs
- Get-ScheduledTaskInfo — Microsoft Learn