GitHub Actions

GitHub Actions has no lockfile system to pin exact versions of third-party actions. Every workflow run re-resolves dependencies from the manifest without recording what was actually chosen, creating non-deterministic builds and enabling supply chain attacks. This is a fundamental gap compared to mature package managers.

GitHub Actions operates as a general-purpose platform lacking optimizations for domain-specific tasks. AI workflows need GPUs and long-running checkpointed jobs; testing needs centralized reporting and test-specific diagnostics; data pipelines require specialized optimization—all missing from the generalist platform.

GitHub Actions requires explicitly naming required status checks, but in monorepos with dynamic pipelines, only relevant checks should be mandatory. If a PR only touches `api1` but `web-app1` checks aren't triggered, the PR cannot merge even though all relevant checks passed. This forces developers to run unnecessary pipelines just to satisfy merge requirements.

The GitHub Actions log viewer is unreliable and crashes browsers when viewing long build logs or searching through them. Developers report that Chrome crashes repeatedly when trying to debug failed builds, making it the only major CI system with this critical usability issue.

GitHub applies breaking changes to Actions with insufficient notice (e.g., self-hosted runner version rejections). When production deployments depend on Actions, forced updates can require hours of investigation and testing to fix stable workflows, with no option to skip upgrades.

Security Vulnerability is the most prevalent issue reported in the GitHub Actions ecosystem according to empirical analysis of GitHub Discussions and Stack Overflow. The Marketplace contains actions of varying quality and security posture, posing risks to users who rely on community-maintained code.

99.8% of GitHub Actions workflows are over-privileged, meaning repositories grant excessive permissions that increase vulnerability to attacks. Secrets are scoped at repository or organization level, flowing broadly by default in reusable workflows without fine-grained controls to bind credentials to specific execution contexts.

Pipeline files (GitHub Actions, GitLab CI, etc.) change without version control, making it impossible to track or debug regressions. Pipeline logic is not treated as critical code, causing unpredictable behavior and deployment failures.

GitHub Actions encourages poor practices because common tasks (e.g., sending Slack messages) have convoluted official solutions. Developers end up hand-rolling scripts, creating an undocumented black box system that becomes unmaintainable at scale without external tooling like NX.

Modern deployment has evolved from simple 'push to main' workflows into complex orchestration involving Docker, Kubernetes, GitHub Actions, preview environments, and rollback strategies. Developers must manage multiple moving parts, making deployment an engineering discipline itself.

Debugging failed builds in GitHub Actions requires multiple page loads and clicks, each with significant loading spinners. Navigation is unreliable—the back button behaves unpredictably, forcing developers to memorize URLs or search browser history. The entire debugging experience is described as navigating bureaucratic forms.

GitHub does not release Docker containers matching the public runner images. Self-hosted runners have poor support for rootless Docker-in-Docker and other standard configurations. GitHub expects users to do 90% of the work to maintain self-hosted infrastructure, yet charges for the service.

Teams experience significant delays in build start times during peak hours, with queue times blocking development velocity. Concurrency limits prevent larger organizations from running multiple projects efficiently, creating major productivity losses.

Companies struggle with prolonged CI/CD tool migrations, often running legacy pipelines (Jenkins, Azure DevOps) alongside new ones (GitHub Actions, GitLab CI) for extended periods. The time investment required to set up and migrate pipelines is so significant that some organizations abandon migration plans entirely.

Deploying a basic webapp to AWS requires navigating IAM Identity Center, SSO, permission sets, IAM roles, GitHub Actions/CodeBuild integration, OIDC setup, and service selection (Amplify vs CodeCatalyst vs others) before any code runs. Without pre-existing CI/CD infrastructure, the process is prohibitively complex compared to platforms like Vercel.

Implementing solid CI/CD pipelines in Azure DevOps or GitHub Actions is complicated, with frequent failures due to build agent issues, variable management problems, and incorrect pipeline permissions.

GitHub suddenly introduced additional per-minute charges for GitHub Actions minutes in December, breaking established budgets across enterprise teams. No per-second billing option exists, and the announcement left no time for departments to adjust fiscal budgets, creating surprise costs mid-fiscal-year.

The tight integration of GitHub-specific features, particularly GitHub Actions, creates dependencies that make migration to alternative platforms challenging and costly.

GitHub Actions suffers from recurring control plane problems including broker/backend message relay failures, hung logs, unexplained outages, and unsafe default behaviors (e.g., safe_sleep). These are long-standing issues that undermine trust in CI/CD reliability.

The security architecture contains too many edge cases and inconsistencies (e.g., not recommending self-hosted runners in public repos). This expanded attack surface makes it easy to introduce vulnerabilities inadvertently while setting up workflows.

Forgejo and Codeberg maintain GitHub Actions compatibility for user migration, but this locks them into reproducing the same broken architecture (missing lockfiles, no registry, poor security model). The fundamental design flaws are baked into the compatibility layer and cannot be fixed without breaking compatibility.

As pipelines grow, developers must add numerous `if` statements to handle different triggers (push, manual, etc.). Reusing workflows requires boilerplate duplication and managing 30+ YAML files. This creates maintenance burden and makes it difficult to refactor without breaking `needs` clauses.

The previous 10GB cache limit forced teams with large dependencies or multi-language monorepos to have build dependencies evicted before the next workflow run, requiring repeated downloads and slowing builds. While recently increased, this was a long-standing pain point.

GitHub Actions are stateless, making it difficult to reuse computation within VMs without relying on external tools like Make or Just. Even with caching layers, developers cannot reliably persist state between runs, forcing redundant rebuilds and slowing feedback loops.

Debugging issues in GitHub Actions is time-consuming because there is no single comprehensive troubleshooting guide. Developers face delays when errors occur, and the slow feedback loop compounds the difficulty. Documentation is insufficient for complex scenarios.

GitHub Actions provides no simple way to re-run workflows against the tip of a branch, making it difficult to handle transient failures and test workflow changes. Developers must work around this limitation by adding additional triggers, which is unintuitive and slows development velocity.

Workflow syntax errors and broken `needs` clauses are only discovered after pushing code. Linters exist but are imperfect. Developers cannot validate workflows locally before commit, forcing a push-and-wait debugging cycle.

GitHub Actions feels overwhelming for new users due to the range of features, options, and complexity of setting up workflows. The platform's learning curve is especially steep for those new to version control or CI/CD concepts.

Free GitHub-hosted runners perform 4-5x slower than comparable local hardware (e.g., i7-13700H mini-PC). This forces teams running Jenkins locally to accept longer build times (30 min to 40 min) even after parallelization, impacting developer velocity.

Users struggle to find suitable actions in the GitHub Actions Marketplace and evaluate their quality. A survey revealed that 7 out of 25 participants found it difficult to navigate and select appropriate actions, leading some teams to maintain their own local actions instead.

GitHub Actions workflows generated between 150.5 and 994.9 million tons of CO₂ equivalent in 2024, creating a significant environmental concern for companies mindful of their carbon footprint.