Decide in advance. If the scanning service fails or times out, your pipeline either blocks the change or lets it through with a warning. Pick per repo tier, set timeouts so a hung call cannot stall the build for hours, and test the failure on purpose before it happens at a bad moment.
The two failure modes
| Mode | Behavior on scanner failure | Good for | Cost |
|---|---|---|---|
| Fail closed | Check fails, merge or deploy blocked | High risk services | An outage of the scanner stops delivery |
| Fail open | Check passes with a warning and an alert | Lower risk code | A bad change can slip through unscanned |
Neither is right everywhere. A payments service and a docs site deserve different answers.
Separate "scanner found a problem" from "scanner did not run"
These are different events and should look different in the pipeline. A finding is a result. A timeout or API error is an operational failure. If both show as a red X, people learn to rerun until green, and real findings get the same treatment.
Give the operational failure its own status message that says plainly: the scan did not complete, here is who to contact, here is the fallback.
Set limits
GitHub Actions lets you set a maximum run time per step, up to 360 minutes, and a continue on error flag at step level that lets a job pass when the step fails. Used carefully, those two settings implement your fail open choice. A tight timeout on the scan step stops a hung call from consuming the whole job. Use continue on error only for tiers where you chose fail open, and pair it with an alert so the skipped scan is not silent.
A short runbook
- On timeout, retry once, with a short delay.
- If it still fails, apply the repo's chosen mode.
- In fail open mode, record the skipped scan and queue a catch up scan.
- Alert the tool owner, not every developer.
- After recovery, review which merges went through unscanned and scan them.
Test it
Once a quarter, block the scanner's network address in a test repo and watch what happens. You will learn whether your timeout works, whether the message makes sense, and whether the alert reaches anyone.
Ask the vendor too
Ask for the service's historical availability, how outages are communicated, and whether a local or self hosted scan mode exists for a fallback. See also the guidance on deciding fail open or fail closed per system.
Quick check
Should security checks ever fail open?
Yes for low risk tiers, if the skipped scan is recorded, alerted and made up afterwards. Never fail open silently.
How long should the scan timeout be?
Set it a little above your normal worst case, such as a few times the median duration, and adjust from real data.
Sources
Last reviewed: 19 October 2026.
