When GitHub Actions logs disappear: what 120 new storage hosts reveal
A workflow file can stay unchanged while logs or job summaries become difficult to retrieve. It is tempting to blame the latest code change, yet the connection that starts work and the connection that stores its results can be different. GitHub’s October 22 announcement about Actions Blob endpoints highlights that less visible part of a build service.
Two ranges, with both endpoints included
The published additions run from productionresultssa30.blob.core.windows.net to productionresultssa49.blob.core.windows.net, and from productionresultssa100.blob.core.windows.net to productionresultssa199.blob.core.windows.net. Inclusive counting gives 20 plus 100, or 120 hosts. It does not put numbers 50–99 into the newly announced ranges.
The announcement concerns environments using a network allowlist for Actions Blob storage. GitHub says an existing productionresultssa*.blob.core.windows.net rule already covers these additions. Environments listing hosts individually need the new names to avoid interruptions to job summaries and logs. That distinction matters more than the size of the list: the same service expansion can require action in one environment and none in another.
Adding names and broadening a rule are different changes
A wildcard rule can already accommodate new numbered hosts, while an exact list grants access one name at a time. The announcement is therefore a reason to compare the current policy with the published additions, rather than automatically broaden every network rule. The useful question is which precise names the current configuration leaves out.
Turning the ranges into a name set makes omissions easier to find. The authored example builds inclusive arrays, turns each number into a hostname and places those names in a Set. The first image summarizes the range counts; the next shows actual boundary-membership results with the common hostname suffix separated for readability. The set contains only these additions, so compare it alongside existing permitted addresses.
Boundary values make the behavior visible
The executed example included hosts numbered 30, 49, 100 and 199. It rejected 200 and a name ending in .example.org. A hostname containing a familiar string is not necessarily that domain, so exact membership rejects the suffix example. These results verify a local name comparison; they do not verify how a firewall appliance interprets a wildcard or resolves a name.
For a real environment, retrieve current values from the official Meta API and match them to the appliance’s treatment of FQDNs, wildcards and IP addresses. GitHub’s API documentation explicitly labels its sample response as illustrative. Its self-hosted runner reference separately describes domains by function and notes that CNAME resolution may require further rules. Possessing a name list and opening the required connection path remain separate tasks.
The blank space beside a green check
For example, if a results page opens but its log does not, examine job startup and the request that retrieves the log separately. A browser error or a denied destination in network equipment can help narrow down which connection is missing. If the destination lies outside the newly announced ranges, return to the relevant official communication requirements rather than assuming these additions explain the failure. This is a diagnostic example, not a reproduced outage.
The interesting change is outside YAML syntax. As a build service expands, the addresses holding its output expand too. For environments managing individual hostnames, comparing these two ranges with the current list and then checking actual log and job-summary access gives the announcement a clear practical purpose. The official release and runner communication reference below provide the next level of detail for a specific environment.
Sources and further reading
GitHub Docs · Self-hosted runners · Communication
Checked October 24, 2026. Apply network changes using the current official list and your appliance’s hostname semantics.