I’ll go into a much longer explanation below, but first I’ll give a quick summary and not bury the fix.
Sometime between April 24th and 27th, 2026, Github Actions workflow jobs for Dependabot started taking over 15 minutes in two of our Golang projects, compared to the 1 minute they took before. If you look at your past workflow logs around this same timeframe, you may see something similar to this. Notice the jump from 56 seconds, to 13 minutes 23 seconds:
The Quick Fix
This fix (workaround?) does the job as of June 2026 — your mileage may vary in the future as Dependabot or Github’s harness for it continues to change.
To get the build times back down for both the “Dependency Graph” and “Dependabot Updates” jobs, add a go.env file similar to below to the same directory as your go.mod and go.sum files. Make sure you replace the name of your organization as needed - it probably isn’t example-org!
GOPRIVATE=github.com/example-org/*
After adding this environment file, both the graph update and dependency update jobs went back to their previous fast run times.
Read up more on Go module environment variables, and read on for a deeper explanation as to why this makes things fast again.
So, what actually happened here?
Great question! Honestly I wasn’t fully able to find exactly why it changed, but here’s what I found during my investigation that led to the above fix.
Deep dive on the logs
I pulled the Github actions log from the last fast job and the first slow one to compare. The key line ended up being the one that started with Job definition: (once you ignore the timestamp and other metadata).
// Old (fast) logs had this as part of the job definition
"experiments": {..., "goprivate":"github.com/entalas/*"}
// New (slow) logs changed the value
"experiments": {..., "goprivate":"*"}
The rest of the logs started to confirm my suspicion this was a pretty important change that had somehow been made.
# Old (fast) logs looked like this - only two entries per dependency, using proxy
proxy | 2026/04/23 20:06:45 [054] GET https://proxy.golang.org:443/github.com/amacneil/dbmate/v2/@v/v2.32.0.mod
proxy | 2026/04/23 20:06:45 [054] 200 https://proxy.golang.org:443/github.com/amacneil/dbmate/v2/@v/v2.32.0.mod
# New (slow) logs looked like this - more work to do the same thing, and slower due
# to no proxy usage and having to follow redirects and use the Git Smart HTTP protocol
proxy | 2026/04/27 14:36:39 [180] GET https://github.com:443/amacneil/dbmate/info/refs?service=git-upload-pack
proxy | 2026/04/27 14:36:39 [180] * authenticating git server request (host: github.com)
proxy | 2026/04/27 14:36:39 [180] 200 https://github.com:443/amacneil/dbmate/info/refs?service=git-upload-pack
proxy | 2026/04/27 14:36:39 [183] POST https://github.com:443/amacneil/dbmate/git-upload-pack
proxy | 2026/04/27 14:36:39 [183] * authenticating git server request (host: github.com)
proxy | 2026/04/27 14:36:39 [183] 200 https://github.com:443/amacneil/dbmate/git-upload-pack
proxy | 2026/04/27 14:36:40 [188] GET https://github.com:443/amacneil/dbmate/info/refs?service=git-upload-pack
2026/04/27 14:36:40 [188] 200 https://github.com:443/amacneil/dbmate/info/refs?service=git-upload-pack (cached)
proxy | 2026/04/27 14:36:40 [192] POST https://github.com:443/amacneil/dbmate/git-upload-pack
proxy | 2026/04/27 14:36:40 [192] * authenticating git server request (host: github.com)
proxy | 2026/04/27 14:36:40 [192] 200 https://github.com:443/amacneil/dbmate/git-upload-pack
proxy | 2026/04/27 14:36:40 [196] POST https://github.com:443/amacneil/dbmate/git-upload-pack
proxy | 2026/04/27 14:36:40 [196] * authenticating git server request (host: github.com)
proxy | 2026/04/27 14:36:41 [196] 200 https://github.com:443/amacneil/dbmate/git-upload-pack
A brief tangent on the Go Module Proxy
The go mod command uses a Go Module Proxy by default to make module and package resolution far quicker than needing to use the underlying VCS URL that packages are typically named by. For the github.com/amacneil/dbmate/v2 package I used as an example in the logs above, the proxy can make a few things really fast:
- Get a list of module versions: https://proxy.golang.org/github.com/amacneil/dbmate/v2/@v/list
- Get the
go.modfile forv2.23.0of the package: https://proxy.golang.org/github.com/amacneil/dbmate/v2/@v/v2.32.0.mod - By changing the extension to
.zipinstead of.mod, you can also get the source code for the given module version.
The alternative would be using the git-upload-pack HTTP service as the slow path did above. This involves fetching a specific file from the Git repo at a specific tag, which will be significantly slower than something that can be served from a CDN.
There is a ton more here that I haven’t touched on, including the module checksum database and other steps taken to authenticate modules.
What is important to know is that the GOPRIVATE environment variable we ultimately use to speed the jobs back up is the default value for GONOPROXY and GONOSUMDB. Thus, setting GOPRIVATE to glob match everything, which is what the slow job started doing, causes the Go module proxy and checksum databases to be completely bypassed, both slowing stuff down as well as removing a layer of security in ensuring checksums were not tampered with.
Relevant dependabot changes
I looked through the core dependabot code for code changes, pull requests, or issues that may have changed something, but couldn’t find anything in the right timeframe. I’m guessing the actual change happened in the harness and job definition Github has for the dependabot/update-graph and dependabot/dependabot-updates workflows, which I can’t find a public definition for.
Eventually through some searching I found Allow specifying a custom GOPRIVATE in dependabot.yml (#7254) from 2023, which let me test setting GOPRIVATE to a value I control, rather than whatever was doing it in the dependabot workflow harness.
An earlier change in 2022, Allow configuration of GOPRIVATE (#4568), hints at the exact optimization we are restoring.
This commit popped up in my search, but I couldn’t pin anything directly to it, and the timeframe didn’t match.
As I was writing this blog post, Add GONOPROXY/GONOSUMDB env vars to go_modules FileParser (#15159) appeared in the dependabot-core repository. It seems like they have been getting crushed by this very bug:
… so every public module also bypasses proxy.golang.org and triggers a full git clone causing disk exhaustion on the updater.
So you may just be able to wait this one out and things will start working better again soon! With that said, I’m not sure how long it takes code to go from the dependabot repo to actual production usage in the Github workflow.
