GitHub code scanning accepts a gzip compressed SARIF file up to 10 MB and rejects anything larger. Within a file it allows 20 runs, 25,000 results per run, and keeps only the top 5,000 results by severity. Plan your output so the findings that matter survive these limits.
The limits in one table
These figures come from GitHub's current documentation on SARIF support for code scanning.
| SARIF data | Maximum | What happens above it |
|---|---|---|
| Compressed file size | 10 MB per gzip file | Upload rejected |
| Runs per file | 20 | None listed |
| Results per run | 25,000 | Only top 5,000 included, by severity |
| Rules per run | 25,000 | None listed |
| Tool extensions per run | 100 | None listed |
| Thread flow locations per result | 10,000 | Only top 1,000 included |
| Locations per result | 1,000 | Only 100 included |
| Tags per rule | 20 | Only 10 included |
| Alert limit | 1,000,000 | None listed |
The documentation says too many results should be handled by changing configuration so the analysis focuses on the most important rules, for example turning off the noisiest queries.
Reading the table correctly
Two different things can happen. A file over the size limit is rejected whole. A file over a count limit is accepted, but truncated. Truncation is the dangerous one, because nothing fails and users simply see fewer alerts than your tool produced.
Because truncation keeps the top results by severity, a tool that does not set severity well gets arbitrary survivors. This is why the security-severity property matters; see how GitHub maps scores to levels.
How to stay inside the limits
- Compress before you measure. The limit applies to the gzip file, so test the compressed size.
- Split by tool. A run holds results for one tool only, and splitting keeps each run smaller.
- Cap noisy rules. If one rule produces thousands of results, fix or tune it, because an alert nobody reads is not protection.
- Trim thread flow detail where you can. Long data flow paths add many locations.
- Count results in CI. Fail the job or warn when a run nears 5,000, so you notice truncation.
- Keep tags short. More than 10 per rule are dropped.
Check the file before you upload
The documentation points to the Microsoft SARIF validator for testing compatibility with GitHub's ingestion rules. Run it in CI on the file you are about to upload. A schema valid file can still be useless, so also check that every result has a rule, a message and a location.
Also remember that code scanning only supports SARIF version 2.1.0, and uses only a supported subset of properties, even though any valid 2.1.0 file can be uploaded.
Try it yourself
Click through it at your own pace, or open it full screen. See how findings show up on a pull request, and think about what a reviewer would miss if only the top few appeared.
Where this fits
Limits like these are a reason to filter at the source. See Safeguard CLI with GitHub Actions and SARIF. Safeguard also offers policies and gates for pull requests, and the free scan shows what a first pass looks like.
Quick check
Is the 10 MB limit before or after compression?
The documentation says each gzip compressed SARIF file can be up to 10 MB, so it applies to the compressed file.
Do I get an error if I exceed 25,000 results?
The table lists 25,000 as the maximum per run and says only the top 5,000 are included, prioritized by severity. Treat anything above 5,000 as at risk of being cut.
Sources
Last reviewed: 19 October 2026.
