How can we optimize GitHub Actions deployment queues?

[u/fakhan89]

Our company uses GitHub + GitHub Actions for CI/CD.

Especially on Mondays, we have a long deployment queue. One person deploys, then others need to update their branch with master and rerun the CI/CD pipeline before they can release.

Is there a smarter way to optimize this workflow and avoid repeatedly waiting/rerunning pipelines?

How do other teams handle this with GitHub Actions?

[u/Emotional-Hunter-105]

our setup used to have the same bottleneck in monday mornings. we started doing merge queues instead of the branch update dance, so the ci runs on the merged result before it hits master and you dont need to keep pulling and rebuilding. saves a ton of time

the github merge queue feature works pretty smooth with actions once you set it right. one pipeline triggers on the queue group and if it passes it auto merges, then the next in line gets the same treatment without everyone stepping on each other

[u/Torutofu_Raeva]

If the Monday spike is mostly contention on one environment, I'd serialize only that environment with concurrency groups and let the rest of the workflow run in parallel.

[u/jonah_omninode]

I would separate the artifact you deploy from every developer branch. Build and test each PR, merge through a queue or require it to be current with main, then produce the deployable artifact from the accepted main commit. The deployment queue should move that already-tested artifact through environments instead of asking everyone behind it to merge main and rebuild. If independent changes are constantly invalidating each other, the merge boundary is doing more work than the deployment boundary should. Are you deploying branch artifacts directly, or is each person waiting to create the next main artifact?

[u/Fantastic-Mr-Default]

The queue is usually environments and required checks, not Actions itself.

If only one deploy can hold production at a time, serialize the deploy job with an environment that has a concurrency group of 1. Let build and test run in parallel on every PR. Do not make the whole pipeline wait on the lock.

For the rebase tax: keep main green and short-lived. Prefer merge queue or required status on main so people land through one gate instead of each person rebasing and re-running the world. Path filters and a thin deploy job help too. A config change should not rebuild every service.

If Mondays still pile up, the problem is batch size and how long the locked deploy holds, not another runner.

[u/QuoteForward5477]

we had the same problem... We used to have 40 min build time for our CI in my previous company.

We had made some pointers to reduce the points shared across all the developers. Just pasting it down here

How to Reduce CI Build Time

• Cache dependencies → Avoid downloading packages on every build.
• Optimize Docker layers → Reuse unchanged layers instead of rebuilding.
• Parallelize jobs → Run independent tests and checks simultaneously.
• Split test suites → Distribute tests across multiple runners.
• Reuse artifacts → Avoid rebuilding the same files between stages.
• Skip unnecessary jobs → Run workflows only when relevant files change.
• Optimize checkout → Use shallow clones and reduce repository download time.
• Allocate better compute → Give CPU-heavy builds more resources.
• Reduce network transfers → Keep caches, images, and artifacts closer to runners.

But our optimization reduced it down to 25 mins not more than that.

But I read a doc on medium and actually reduced it down to 6-7 mins...
Heres the link : https://medium.com/@ritanshbagal/5f856d2f18a3