4.3.3. Disabling vs. Deleting Workflows
💡 First Principle: Disabling is a state change on an existing workflow — reversible, non-destructive, preserving file and history — while deleting means removing the file from the repository; the difference is whether you intend to come back.
Disable a workflow from the Actions tab (the "..." menu → Disable workflow), via gh workflow disable, or via PUT /repos/{owner}/{repo}/actions/workflows/{id}/disable. The effect: no new runs are triggered by any event, the workflow still appears in the list marked disabled, the YAML file remains in the repository, and all past runs and their logs and artifacts are untouched. Re-enabling restores triggering immediately. This is the correct answer for a noisy or broken workflow during an incident, or for pausing a scheduled job — and note GitHub automatically disables scheduled workflows after 60 days of repository inactivity, which candidates often misread as deletion.
Deleting means removing the .yml file with a commit. New runs stop because there's no definition, the workflow disappears from the Actions sidebar once no runs remain associated, but historical runs persist — you can still open them and read their logs until their retention expires. (Deleting individual runs is a separate operation, via the UI or DELETE .../actions/runs/{run_id}.)
Two related states complete the picture: Actions can be disabled repository-wide (Settings → Actions → Disable Actions), which stops everything at once, and organization or enterprise policy can disable Actions for a whole set of repositories. When a scenario says "no workflows run anywhere in this repository despite valid files," check the repository-level Actions setting before the individual workflow states.
⚠️ Exam Trap: Deleting a workflow file does not delete its run history, and disabling a workflow does not delete anything at all. If a question's requirement is "remove the evidence" or "reclaim storage," neither operation is sufficient — that requires deleting runs and artifacts explicitly.
Reflection Question: A scheduled workflow "stopped working" on a repository with no commits for three months, and the file is still present and enabled-looking. What happened, and what single action restores it?
