GitHub Runner Brownouts Start: Check Proxy Egress Before Jobs Stall

GitHub's published enforcement schedule places GitHub Enterprise Cloud self-hosted runners in a new brownout phase beginning September 14, 2026. Additional config-and-runtime brownouts are scheduled for September 16 and 18, with full enforcement planned for September 25. For teams that run authorized data collection, browser testing, ad verification or market-research jobs on self-hosted infrastructure, the risk is not only an old runner binary. A proxy, firewall or private certificate path can prevent an otherwise healthy runner from updating, registering or maintaining service connectivity.

GitHub also announced a runner-deprecation REST API on September 3. It returns the runner version plus registration and runtime deprecation timestamps, giving platform teams a machine-readable way to detect risk before jobs remain queued.

This is an operational readiness event, not a proxy product change. The useful response is to inventory runner versions, validate the control-plane path through the existing network policy, and canary a representative job before the next brownout window.

What GitHub has announced

GitHub's official timeline states two distinct requirements for GitHub Enterprise Cloud self-hosted runners:

• version 2.329.0 or later is required to configure or re-register a runner on the new architecture;
• to execute jobs, a runner must keep up with new releases within 30 days of publication.

The registration minimum is not a permanent execution minimum. A runner pinned to one old image can become ineligible as the moving execution requirement advances. GitHub says critical security updates can also pause job queueing until the runner is updated.

The September 14, 16 and 18 brownouts are scheduled for 11:00 a.m. to 3:00 p.m. Eastern Time. During this phase, unsupported runners can be intermittently blocked from registration and job execution. Full enforcement for GitHub Enterprise Cloud is scheduled for September 25. GitHub Enterprise Server is not included in this specific schedule.

Why proxy-enabled runners need a separate check

Auto-update only works when the runner can reach the required service through the approved network path. A runner may appear online yet fail at the next update or re-registration because:

• the proxy allowlist covers repository traffic but not runner update traffic;
• a proxy credential has expired or is scoped to the wrong worker group;
• an enterprise TLS inspection certificate is missing from the runner image;
• HTTP_PROXY, HTTPS_PROXY or NO_PROXY behavior differs between the service account and an interactive shell;
• DNS for the proxy gateway or service endpoint resolves differently in the runner network;
• a cached virtual-machine or container image contains an outdated runner;
• a sticky egress route changes during a long update or job session;
• retry logic turns a brownout response into a connection storm.

Do not solve these failures by bypassing the corporate proxy or widening outbound access without review. The goal is to prove the approved path and document the smallest necessary rule.

Run this readiness check now

1. Inventory every active runner

Record runner name, operating system, runner version, image or installation source, auto-update setting, owner, proxy route and last successful job. Include ephemeral pools and autoscaling templates; a clean-looking inventory of currently online machines can miss old images that will be created later.

Use the new deprecation endpoint at repository, organization or enterprise scope where your permissions allow it. Compare both returned timestamps. Treat an unknown or unparsable response as an inventory failure rather than assuming support.

2. Test under the real service account

Run connectivity diagnostics using the same identity, environment and service manager that launches the runner. An administrator's shell can inherit different proxy variables, trust stores and DNS settings.

Confirm:

• the runner starts and reports its expected version;
• proxy variables use the approved gateway and do not embed secrets in logs;
• the proxy can establish the required HTTPS tunnel;
• the runner trusts the intended certificate chain;
• no sensitive internal host is accidentally sent through the proxy;
• credentials can be retrieved from the approved secret store;
• an update check completes without repeated authentication prompts.

Redact proxy usernames, passwords, tokens, cookies and complete request headers from diagnostic output.

3. Classify failures before retrying

Different errors need different owners:

Avoid rotating exit IPs to escape a control-plane rejection. A version-policy response is not a route-quality problem.

4. Rebuild the source image

If runners are created from a golden image, container or bootstrap script, update the source rather than patching only live machines. Verify the binary version after provisioning, not merely the package version recorded in a build log.

Keep rollback available, but do not roll back to an unsupported runner. Preserve the previous network and proxy configuration separately so you can distinguish a runner update regression from an egress-policy change.

5. Canary a production-shaped job

Choose a small, authorized workflow that exercises the important boundaries without causing external load. The canary should cover checkout or artifact access, approved proxy authentication, DNS, TLS, one lightweight destination request, result validation and log redaction.

Run it on one updated runner while older capacity remains available. Compare queue time, registration events, connection setup, first-attempt success, proxy 407s, TLS failures and final cleanup. Then increase the updated pool gradually.

The proxy egress-attestation guide can help record the intended path. If an exit address is part of an allowlist, follow the proxy allowlist rollover procedure instead of changing addresses without overlap.

Add a brownout-specific monitor

For each scheduled window, watch these signals by runner pool and image version:

• runner registration and re-registration failures;
• jobs queued without an eligible runner;
• job start and completion rates;
• proxy authentication and tunnel failures;
• TLS validation errors;
• update-check failures;
• connection retries per logical job;
• sudden changes in outbound route or ASN;
• canceled jobs and incomplete cleanup.

Use a correlation identifier that joins runner lifecycle, job, proxy route and final result without exposing credentials. Preserve evidence from before, during and after the window. A four-hour average can hide a sharp 20-minute failure.

Update workflow identity checks too

GitHub's September 3 announcement also added reusable-workflow job context properties for the defining workflow reference, SHA, repository and file path. Where those fields are available, they can strengthen change attribution: the job can record which reusable workflow actually defined it rather than relying only on caller-level context.

Treat this as an observability improvement, not authorization by itself. Do not place untrusted event data directly into shell commands, proxy configuration or destination URLs. Keep workflow permissions minimal and protect network credentials with the platform's secret controls.

The GitHub Actions proxy cache guide provides a related example of testing CI network behavior without hiding failures behind a shared cache.

Readiness checklist

• [ ] Every persistent and ephemeral runner source is inventoried.
• [ ] Version and deprecation timestamps are collected.
• [ ] The test runs under the actual runner service account.
• [ ] Proxy settings contain no embedded credentials in logs or images.
• [ ] HTTPS tunnel, DNS and TLS trust checks pass.
• [ ] Golden images and bootstrap scripts create a supported runner.
• [ ] A production-shaped canary passes on the updated pool.
• [ ] 407, TLS, DNS, timeout and version-policy errors are separated.
• [ ] Retry attempts are bounded and jittered.
• [ ] Brownout monitoring groups results by runner and image version.
• [ ] Rollback preserves a supported version and approved network policy.
• [ ] GitHub Enterprise Cloud and GitHub Enterprise Server scope are not confused.

FAQ

Is version 2.329.0 permanently sufficient?

No. GitHub describes it as the registration minimum for the new architecture. Execution eligibility moves as new runner releases are published, and runners must remain current within the stated window.

Does this schedule affect GitHub Enterprise Server?

GitHub says the September Enterprise Cloud enforcement schedule does not apply to GitHub Enterprise Server. Teams should still follow the support policy for their installed server version.

Can a proxy make an eligible runner look outdated?

The proxy does not change the local version, but it can block updates, registration or service communication. Diagnose local version and network reachability as separate layers.

Should we bypass the proxy during the brownout?

Not as a routine fix. Validate the approved route and request the smallest reviewed policy change if a required service endpoint is blocked. Emergency bypasses can create security and audit gaps.

What should trigger rollback?

Rollback when the new runner image introduces a verified regression and the previous image remains supported. Do not roll back to a version that the service will reject.

Compliance note

Use self-hosted runners and proxies only for lawful, authorized workflows. Respect destination terms, access policies, rate limits, privacy obligations and organizational network controls. Do not use alternate routes or address rotation to evade GitHub enforcement or destination restrictions. Protect secrets, minimize logs and obtain review before changing outbound policy.

Sources reviewed internally: GitHub Changelog, “GitHub Actions: Early September 2026 updates,” September 3, 2026; GitHub Changelog, “GitHub Actions: Minimum version enforcement timeline for self-hosted runners,” June 12, 2026.