GitHub Actions Rebuilt: What 71 Million Daily Jobs Taught Them

TL;DR

• GitHub Actions re-architected its entire backend to handle 71 million jobs per day (up from 23 million)
• The rebuild delayed feature work but enabled YAML anchors, deeper reusable workflows, larger caches, and non-public templates
• Q1 2026 brings timezone support, workflow dispatch run IDs, and parallel steps by mid-year
• If you run complex CI/CD at scale, these changes remove real bottlenecks. If you're on simple workflows, you won't notice much

The Big Picture

GitHub Actions hit a wall in early 2024. The platform was processing 23 million jobs daily, but growth curves don't lie. The existing architecture couldn't scale, and the team faced a choice: keep shipping features on a crumbling foundation, or rebuild the engine while the car was moving.

They chose the rebuild. It was a bet that cost them feature velocity for over a year. The community noticed. Long-standing requests piled up. But the new architecture now handles 71 million jobs per day—over 3x the original load—and individual enterprises can start 7x more jobs per minute than before.

This wasn't just infrastructure work. It was a prerequisite for everything developers have been asking for: better caching, workflow flexibility, and reliability at scale. The foundation is done. Now the features are shipping.

GitHub Actions powers how most teams build, test, and deploy software. When it breaks, your entire pipeline stops. When it scales poorly, your builds queue. This rebuild matters because it determines whether Actions can handle the next decade of CI/CD workloads—or becomes the bottleneck that forces teams to look elsewhere.

How It Works

The re-architecture wasn't a single change. It was a complete overhaul of the backend services that orchestrate every job and runner. The goals were clear: improve uptime, reduce internal throttles, and scale 10x beyond existing usage.

By August 2024, all GitHub Actions jobs ran on the new architecture. The migration wasn't smooth—it slowed feature development and introduced stabilization issues—but it gave GitHub the visibility and control they needed to diagnose performance problems across the platform.

The payoff shows up in the numbers. Usage jumped 35% year over year in 2025, with developers burning through 11.5 billion Actions minutes in public and open source projects alone. The old system would have collapsed under that load. The new one handles it and has headroom to grow.

With the foundation stable, GitHub started shipping the quality-of-life improvements that had been stuck in the backlog. YAML anchors landed in September, addressing one of the most upvoted feature requests. They let you define configuration once with an anchor (&) and reference it with an alias (*), cutting down repetitive environment variables and step configs across jobs.

Non-public workflow templates followed, solving a pain point for organizations that wanted private, reusable CI scaffolding. Instead of copying workflow patterns across repos, teams can now pull from a shared .github repository. It's a small change that removes a ton of manual duplication.

Reusable workflow depth increased from 4 to 10 levels, with support for 50 workflow calls per run. For teams building modular pipelines, this removes artificial limits that forced awkward workarounds. You can now structure CI/CD the way your architecture demands, not the way GitHub's old limits forced you to.

The cache limit bump is the most tangible improvement for large projects. The old 10GB cap meant dependencies got evicted before they could speed up subsequent runs. Teams with multi-language monorepos or heavy build pipelines hit this constantly. The new architecture removes the hard cap, letting repos scale cache storage based on actual need.

Workflow dispatch inputs jumped from 10 to 25, giving teams more flexibility to parameterize deployments and build self-service automation. It's not flashy, but if you've ever hit the 10-input limit while building a complex deployment workflow, you know why this matters.

GitHub also shipped arm64-hosted runners for public repos, macOS 15 and Windows 2025 images, and Actions Performance Metrics (now generally available). Custom Image support entered public preview, letting teams run workflows on tailored environments instead of GitHub's standard images.

What This Changes For Developers

If you're running simple CI workflows—linting, unit tests, basic deployments—you probably won't notice much. These changes target teams at scale: large monorepos, complex pipelines, organizations with dozens of repos sharing common patterns.

YAML anchors cut down workflow file bloat. If you've been copy-pasting the same environment variables across 15 jobs, you can now define them once and reference them everywhere. It's a readability win as much as a maintenance win.

Non-public workflow templates matter if you're managing CI across multiple teams. Instead of every team reinventing the wheel, you can provide a standard starting point. It's the difference between "figure it out yourself" and "here's the approved pattern."

The cache limit increase is a direct speed improvement for dependency-heavy builds. If your workflow downloads gigabytes of dependencies every run because the cache kept evicting them, that pain is gone. Builds get faster. Developers wait less.

Deeper reusable workflows let you build more sophisticated pipelines without hitting arbitrary nesting limits. If you've been flattening your workflow structure to stay under the old 4-level cap, you can now organize it the way it should be organized.

The architecture rebuild also sets up what's coming next. Parallel steps—one of the most requested features—is slated for mid-2026. That's a fundamental change to how workflows execute, and it's only possible because the backend can now handle the orchestration complexity.

What's Coming Next

GitHub laid out their Q1 2026 roadmap, and it's focused on removing friction. Timezone support for scheduled jobs is coming, along with reliability improvements for cron triggers. If you've ever debugged why a scheduled workflow didn't fire, you know this is overdue.

Workflow dispatch will return the run ID when triggered, making it easier to track and monitor programmatically triggered workflows. Expression functions are getting a case/conditional operator, reducing the need for awkward workarounds in complex conditionals.

UX improvements include faster page loads, better rendering for workflows with over 300 jobs, and a filter for the jobs list. These are table stakes for teams running large-scale CI/CD, and they've been missing for too long.

Parallel steps is the big one. It's scheduled for mid-2026, and it fundamentally changes how you structure workflows. Instead of running steps sequentially within a job, you'll be able to run independent steps concurrently. For workflows with long-running steps that don't depend on each other, this could cut execution time significantly.

GitHub is also committing to raising the bar on their open source repositories and increasing funding for Actions development. Whether that translates to faster feature delivery remains to be seen, but the intent is clear: they know they've been behind on community requests.

The Bottom Line

Use GitHub Actions if you're already in the GitHub ecosystem and your workflows fit within its model. The architecture rebuild removed real scaling bottlenecks, and the feature backlog is finally moving. The cache improvements alone justify sticking with Actions if you were considering alternatives.

Skip it if you need features that still aren't on the roadmap, or if you're running workflows that require more control than GitHub's hosted runners provide. Custom images are in preview, but if you need full infrastructure control, you're still better off with self-hosted runners or a different CI platform.

The real risk here is execution. GitHub spent a year rebuilding the foundation and delaying features. They're promising faster delivery in 2026, but they've burned community trust by letting requests sit for years. Parallel steps by mid-2026 is a concrete commitment. If they miss it, or if the quality bar doesn't improve, teams will start looking elsewhere. The architecture can scale now. The question is whether GitHub can deliver features at the pace their growth demands.

If you're building automation workflows that integrate with GitHub's broader platform—like the WRAP framework for Copilot or continuous efficiency patterns—Actions is still the most natural fit. Just keep voting on the community discussions. That's the only signal GitHub seems to prioritize.

Source: GitHub Blog