What changed
GitHub's changelog entry from October 22, 2026 says the company is adding blob storage endpoints for GitHub Actions on github.com as part of ongoing work on capacity and reliability. The Meta API now lists them. This is an infrastructure change, not a new Actions feature, and it requires no change to workflow files.
The two new inclusive hostname ranges, all under blob.core.windows.net, are:
- productionresultssa30 through productionresultssa49, which is 20 hosts.
- productionresultssa100 through productionresultssa199, which is 100 hosts.
That makes 120 new hostnames. Both ranges are inclusive, so the allowlist must cover every number in between. Adding only the first and last names of each range is not enough.
Who needs to act
GitHub's guidance depends on how your egress rules are written:
- You allow the wildcard productionresultssa*.blob.core.windows.net. No change is needed.
- You allow individual hosts. Add the new hosts to avoid interruptions to job summaries and logs.
- *You allow all of .blob.core.windows.net.** GitHub's runner documentation lists that broader wildcard among the domains needed for uploading and downloading job summaries, logs, workflow artifacts and caches. This setup is already covered. Many security teams reject it because it opens every Azure storage account.
This is a domain-name allowlist matter. It is separate from the IP ranges GitHub publishes for hosted runners. GitHub's runner docs also say some listed domains use CNAME records. Some firewalls need rules for those records too, and only the listed domains are guaranteed to stay constant.
Why the host-by-host approach is fragile
Administrators have struggled with this hostname family for years. A 2023 GitHub community discussion asked for a full list of the productionresultssa hosts. A reply said no public list of all productionresultssa*.blob.core.windows.net domains existed at the time. The asker's firewall could only wildcard at the subdomain level, not in the middle of a hostname.
Recent public repositories show the same pattern, which is community evidence rather than GitHub documentation:
- One project's proxy rule allowed productionresultssa0 through productionresultssa19. That fits the earlier set of 20 accounts that the new ranges now extend.
- Another team found its enumerated allowlist omitted observed accounts, which blocked normal GitHub downloads. It fixed this by adding a pattern rule.
- A third saw a Forbidden error from a refused proxy connection to a numbered storage host. The error looked like a token permission problem, which sent people debugging the wrong thing.
The practical lesson is that the failure often looks like an authorization problem when it is a network block. The API call succeeds and then the redirected download is refused.
Checklist
- Find out whether your proxy, firewall or egress policy uses the wildcard or lists hosts individually.
- If it lists hosts, add all 120 new names and keep the existing ones.
- Pull the current list from the Meta API using the REST endpoint for meta data (GET /meta). Compare it with your rules instead of relying on a remembered list.
- After the change, test log and artifact downloads. Check job summaries and logs in the Actions UI. For command-line access, try gh run view with the log option.
- If a download fails, check your proxy's deny logs for a productionresultssa host before you suspect tokens.
Analysis
Whether to use the wildcard is a trade-off. A mid-label wildcard such as productionresultssa* keeps the rule narrow. It still saves you from editing it every time GitHub adds capacity. Some firewalls can only wildcard a leading label, so they cannot express it. In that case you must enumerate hosts, accept a broader rule, or work out another approach with your vendor or GitHub Support. Which is right depends on your security policy. Teams that block Azure storage to prevent data exfiltration will want to keep it narrow.
Teams that enumerate hosts can expect more of these updates. Growth in the numbered storage accounts means a static list will keep going stale. Automating the sync from the Meta API is cheaper than getting paged because logs went blank.
The changelog does not say when the hosts go live. It does not address GitHub Enterprise Cloud with data residency. It does not say what the failure looks like in a workflow run beyond lost summaries and logs. Check your own environment instead of assuming.