GHES may fail to upload a support bundle during an incident: what to check before August 18

The bundle exists, but the upload fails

Imagine a GHES outage: developers cannot work normally, the team has created a support bundle, but the CLI cannot send it to GitHub Support. People are waiting for a diagnosis, yet the usual escalation path has stopped working when every minute matters.

Until that moment, the environment may have appeared ready for an incident. Backups run, servers are reachable, and monitoring is green. None of those checks proves that diagnostic data can reach external support.

That is the risk teams need to address before August 18, 2026. Readiness requires testing the entire route: identify the installed version, create the bundle, upload it through an approved channel, and confirm that support can receive it.

What changes on August 18

GitHub has announced that, starting August 18, 2026, it will reject CLI support bundle uploads from GHES instances that do not have the required security patches. The change affects workflows that use these commands:

• ghe-support-bundle;
• ghe-cluster-support-bundle;
• ghe-support-upload.

There is an important practical distinction: creating an archive and uploading it are separate steps. A bundle may appear successfully on disk while its upload is rejected. Checking only the exit status of the first command creates false confidence.

For the branches listed in the announcement, the minimum versions are 3.21.3, 3.20.5, 3.19.9, 3.18.12, and 3.17.18. An instance below the minimum patch in its corresponding branch should be marked for an update. Put unsupported branches in a separate category. A simple version comparison is not enough there; the team needs an agreed move to a supported version or a plan coordinated with GitHub Support.

Step 1: Find every instance, not only the primary one

Start with an inventory. For every GHES instance, record its environment, current version, owner, role, and cluster status. Include test and recovery installations if they could become the source of diagnostic data during restoration work.

Useful table fields include the name, address or internal identifier, version, patch branch, support status, applicable minimum version, owner, and date of the latest check. Obtain the version from the system itself or another reliable technical source, not from an old change ticket.

A common mistake is to assume that every cluster node was updated after checking only one of them. If the architecture has multiple nodes, use the normal installation health checks and retain the result as evidence.

Step 2: Turn the update into a controlled change

A label saying patch required is not a complete plan. For every affected instance, define the target version, owner, maintenance window, dependencies, rollback plan, and completion criteria. Before making the change, consult the official update instructions for the installed version and architecture.

Completion evidence should include the actual version reported after the work and the result of a basic service check. A closed ticket or a chat message does not prove that the required patch is running on the target system.

Step 3: Test the complete support bundle route

Run the rehearsal at an agreed time and follow your rules for diagnostic data. A support bundle can contain internal service information, so do not copy it to an arbitrary storage location or transfer it through a personal account.

A complete check should prove that the team can:

1. select the correct command for a standard or clustered installation;
2. create the bundle and record where it was stored;
3. upload it through the approved route;
4. obtain confirmation that it was accepted, rather than relying only on local command success;
5. remove temporary copies according to the data retention policy.

If a real upload requires an active support case, coordinate the test with GitHub Support or verify the procedure in an approved environment. The goal is not to create an unnecessary case. It is to obtain reliable evidence that the emergency path works.

If the update cannot be completed in time

Do not leave this question for an actual incident. GitHub’s announcement advises customers to contact GitHub Support if they cannot install the required patch before the change. Record the approved contact channel, required access, responsible person, and information that can be shared safely at the start of a case.

Do not invent an alternative such as emailing the archive or placing it in an arbitrary cloud drive. That workaround may violate data protection rules and still may not give support engineers an acceptable way to receive the bundle.

Anti-patterns that hide the risk

Several shortcuts make a readiness check look complete when it is not:

• treating an update ticket as proof of the installed version;
• checking only the primary instance or one cluster node;
• testing bundle creation but not upload;
• keeping the only procedure in one administrator’s memory;
• trying the escalation path for the first time during an outage.

Each shortcut verifies an activity rather than the required outcome: support must be able to receive usable diagnostic data when the team needs help.

What to add to the incident runbook

A short entry can look like this:

Condition: a GHES support bundle is required for incident analysis.
Check: instance, version, cluster status, and support case number.
Create: use the approved command for this architecture.
Upload: use only the approved GitHub Support channel.
Confirm: record the upload time and acceptance result.
If rejected: do not publish the archive; use the backup support contact and involve the GHES owner.

The rehearsal is successful when every instance has a known status, affected systems have an owned update plan, post-change versions are verified, and the complete upload path has been tested or an official backup procedure has been agreed.

The broader lesson goes beyond one GHES change: the diagnostic channel is a production dependency. It also needs an owner, a review date, and a regular practical rehearsal.

Sources

• GitHub Changelog — Upcoming GHES change impacting uploading support bundles