Store an on or off value in a repository or organization configuration variable, and make every automation job check it in its first step or in an if condition. When something misbehaves, flip the variable. No code change, no review, and the pause takes effect on the next run.
Why you want one
Automation fails in new ways. A rule is too broad, a webhook storm repeats, a bot opens forty pull requests overnight. The first question in the incident is how to make it stop. If the answer is to edit a workflow file, get a review and merge, you will lose an hour. A switch that anyone on call can flip changes that. Our post on lessons from a runaway maintenance automation incident shows why speed matters.
Use configuration variables
GitHub documents configuration variables for repositories, environments and organizations. They are available in workflows through the vars context, and unlike secrets they are plain text, which suits an on or off flag.
jobs:
sync-tickets:
if: ${{ vars.SECURITY_AUTOMATION_ENABLED == 'true' }}
runs-on: ubuntu-latest
steps:
- run: ./sync.sh
When the variable is missing or set to anything but true, the job is skipped. That fail closed default is deliberate: a typo should stop the automation, not start it.
Steps to roll it out
- Pick one clear name per scope, such as an org wide variable for everything and a repository variable for local control.
- Add the condition to every job that writes: tickets, comments, pull requests, closing alerts.
- Leave read only jobs, such as scans, running, so you keep visibility while writes are paused.
- Document who may change the variable and where. Restrict edit rights on the variable to a small group.
- Test it. Flip the switch in a test repository and confirm the jobs show as skipped.
- Add a notice. When the switch is off, post a message so people know the automation is paused and do not assume a clean result.
Granular switches
One global flag is a start. Consider one per action class too: a flag for ticket creation, one for pull request creation, one for auto closing. During an incident you can then stop the dangerous action and leave the harmless ones alone. Our post on limiting the blast radius of automated fixes goes further.
What a switch does not do
A switch only stops future runs. It cannot undo what already happened, and it does not cancel jobs in progress unless you cancel them in the Actions UI. Pair it with a rollback note, as in the rollback plan template for automated remediation. If the automation runs outside GitHub, in a webhook receiver for example, put the same check in that code and read the flag from your configuration store.
Also remember that the scheduled workflows still start and consume a runner minute even when the job is skipped. That is fine, and it makes the paused state visible in the run list.
Quick check
Should the switch default to on or off when the variable is missing?
Off. A missing or misspelled variable should stop writes, not allow them.
Can I use a secret instead of a variable?
You can, but a flag is not sensitive, and variables are easier to read and audit. Keep secrets for credentials.
Sources
Safeguard's remediation features follow the same default: autonomous remediation is off until you enable it, with every category on Manual. Try the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
