CircleCI is an amazing tool. It automates the way we build, test, and release software. But sometimes, a plan change can disrupt your workflow. That’s exactly what happened to a few developers recently—they noticed that their jobs weren’t running at the same time anymore, and their pipelines slowed down.
TL;DR
Some users noticed that concurrent jobs were disabled after they changed their CircleCI billing plan. This caused pipelines to run slower because jobs could no longer run in parallel. But with a little cleverness, developers used parallelism optimization to keep things moving. Let’s break down how it all works in a simple and fun way!
What are Concurrent Jobs Anyway?
Imagine you’re making a big dinner. If you have one oven, you can only cook one dish at a time. But multiple ovens? Now you’re cooking three things at once!
Concurrent jobs are just like having multiple ovens. Each job is a task in your CI pipeline. When jobs run at the same time, your pipeline finishes much faster.
- One job at a time? Slower builds.
- Many jobs at once? Fast and smooth pipelines.
But what happens when your oven gets taken away?
The Plan Change Surprise
CircleCI offers different plans. Some are free, and others are paid with more features and better performance. When a user switches plans—say, from a free or old starter plan to a new one—they might lose access to multiple concurrent jobs.
This isn’t a bug; it’s by design. The number of concurrent jobs you’re allowed often depends on your credit allotment and plan type. After switching, users might start seeing all their jobs run one-by-one instead of in parallel.
Now the question becomes: “Do we need to pay more?” Not necessarily!
Parallelism to the Rescue!
Enter parallelism optimization. This is a helpful trick that allows a single job to split its work across several threads or containers—even within one job slot. Think of it as slicing a pizza and letting lots of people eat at the same time instead of one person taking tiny bites.
This method doesn’t require multiple concurrent jobs. Instead, one job uses internal techniques to work faster by doing several things at once.
For example, a test suite with 100 tests normally runs them all serially. But with test splitting and parallelism, you can divide those 100 tests among “virtual slices” of the job. Those slices run together.
The result? Speed without adding more jobs!
How It Works: A Bit Technical but Still Fun
Let’s say your pipeline has a job like this:
jobs:
test:
docker:
- image: cimg/node:16
steps:
- checkout
- run: npm test
This runs all your tests in one stream. Now, let’s turn on the magic:
jobs:
test:
parallelism: 4
docker:
- image: cimg/node:16
steps:
- checkout
- run:
name: Split tests
command: |
circleci tests split --split-by=timings tests//*.test.js | xargs -n 1 npm test
By setting parallelism: 4, CircleCI spins up 4 containers—but under one job definition. The tests are then split intelligently based on how long they usually take to run (thanks to CircleCI’s test timing history).
This keeps the build fast, even if your plan allows only one job to run concurrently.
Why CircleCI Did This
CircleCI updated how its billing plans operate. Older plans gave a fixed number of concurrent jobs, but newer plans use credits. These credits are spent based on usage—like how long your jobs run and what resources they need.
This gives teams more flexibility. But if you’re unaware of how parallelism works, you might think your jobs are crawling.
So CircleCI isn’t punishing you—they’re helping you manage resources more efficiently. And understanding that gives you power.
Tips to Keep Your Pipelines Happy
Here are a few tricks to keep things moving quickly, even with fewer job slots:
- Use parallelism inside jobs like we showed above.
- Split tests using
circleci tests split. - Cache dependencies to avoid downloading the same stuff all the time.
- Use workflows to order jobs smartly and avoid bottlenecks.
- Tune your Docker resources by choosing optimized base images.
Work smarter, not harder!
Common Mistakes to Watch Out For
Many developers struggled with these issues during the plan change:
- Not realizing that concurrent jobs weren’t available under the new plan.
- Assuming parallelism and concurrency are the same thing (they’re not!).
- Forgetting to cache dependencies—leading to longer builds.
- Relying on default workflows that aren’t optimized anymore.
If you fix these, you’ll feel like a CI ninja.
Closing the Loop
Changing plans on CircleCI can be frustrating if you suddenly lose concurrent job access. But it’s not the end of fast builds. With a little optimization and smart use of internal parallelism, you can keep your CI pipelines zooming along like nothing happened.
And hey, maybe wrapping up your testing in half the time without paying more for parallel jobs? That’s a win.
Final Thoughts
CircleCI’s pricing model change might seem sneaky at first. But it pushes us toward better habits. It teaches us to write more efficient jobs, split tests with purpose, and be mindful of resource use.
It’s not magic. It’s just being smart with tools already in your hands.
So remember:
- Concurrency != Parallelism.
- One job can still do more, with the right config.
- Pipelines should be fast AND lean!
Stay curious. Keep optimizing. Happy building!