Use CircleCI Insights to Find and Fix Slow Jobs (2026)

CircleCI Insights can tell you which parts of your CI/CD pipeline are costing you the most time, but it’s not just about spotting the slow jobs; it’s about understanding why they’re slow and how to fix them.

Let’s say you’ve noticed your builds are taking longer and longer, and you want to use CircleCI Insights to pinpoint the culprit. You’d navigate to your project in CircleCI, then click on "Insights" in the sidebar. Here, you’ll see a dashboard with various metrics. The key one for this problem is "Job Duration."

You’ll likely see a graph showing the average duration of your jobs over time. Look for jobs that consistently have a high average duration or a significant upward trend. For instance, you might see a job named test:integration that’s consistently taking 25 minutes, while most other jobs are under 5 minutes. This is your target.

Once you’ve identified a slow job, the next step is to understand its execution. Click on the job name in the Insights dashboard. This will take you to the "Job Details" page. Here, you can see a breakdown of the steps within that job and how long each step took. You might find that a single step, like Run integration tests, is taking up the majority of the 25 minutes.

Now, let’s dive into the common reasons for slow jobs and how to address them.

1. Inefficient Test Suites

Diagnosis: The Run integration tests step is taking 20 minutes. This is often due to tests that are not optimized, run sequentially when they could be parallelized, or are performing redundant setup/teardown operations.

Common Cause:

Lack of Parallelization: Your test runner might be executing tests one after another, even if your CI environment has multiple processors.
Redundant Data Setup: Each test might be rebuilding a database or fetching the same external resources.
Inefficient Test Logic: Individual tests might be slow due to complex queries, network requests, or large data processing.

Diagnosis Command/Check:

Examine your test runner’s configuration. For example, if you’re using RSpec, check your spec_helper.rb or rails_helper.rb for parallelization settings.
Add detailed logging within your test setup and teardown phases to identify repeated operations.
Run tests locally with a profiler to identify slow individual test cases.

Fix:

Enable Parallelization: Configure your test runner to utilize multiple processes. For RSpec, this might involve adding require 'rspec/parallel' to your spec_helper.rb and running bundle exec rspec --parallel. This distributes tests across available cores, often reducing runtime by a factor of N (where N is the number of cores).
Optimize Data Setup: Use database seeding or caching mechanisms. For example, in Rails, you might use Rails.cache or a dedicated library like database_cleaner with efficient strategies (e.g., :truncation instead of :transaction if your database supports it and you’re not relying on transaction isolation).
Refactor Slow Tests: Identify and refactor the slowest individual tests. This might involve optimizing database queries, mocking external services, or breaking down large tests into smaller, more focused ones.

Why it works: Parallelization allows your CI runner to execute multiple tests simultaneously, leveraging its available CPU resources. Optimized setup/teardown reduces the overhead associated with starting and stopping tests. Refactoring slow tests directly addresses the bottlenecks within your test suite.

2. Large Docker Image Dependencies

Diagnosis: The job starts with a checkout step, but then spends a significant amount of time downloading Docker images specified in your circleci/config.yml.

Common Cause:

Uncached Docker Images: Each build downloads all required Docker images from scratch.
Large Base Images: You’re using a very large base image (e.g., a full Ubuntu distribution) when a smaller, more focused image (like Alpine Linux) would suffice.
Multiple Large Images: Your job depends on several large Docker images, and each download adds to the startup time.

Diagnosis Command/Check:

Review your circleci/config.yml to see which Docker images are being used in the docker: section of your job.
Check the size of these images on Docker Hub or your private registry.
Observe the build logs for download times of specific images.

Fix:

Use Docker Layer Caching: Configure CircleCI to cache your Docker layers. In your config.yml, within the jobs section, you can add docker: - image: your/image:tag and then use setup_remote_docker: with caching enabled.
```
jobs:
  build:
    docker:
      - image: cimg/node:18.17.0
    steps:
      - checkout
      - setup_remote_docker:
          docker_layer_caching: true
      # ... rest of your steps
```
This tells CircleCI to cache the layers of the Docker image, so subsequent builds that use the same image tag won’t need to re-download them.
Optimize Base Images: Switch to smaller base images. For example, instead of ubuntu:22.04, consider cimg/base:stable or an Alpine-based image if your dependencies allow.
Consolidate Images: If possible, combine multiple services into a single Docker image or use a single, more comprehensive base image that includes all necessary tools.

Why it works: Docker layer caching ensures that only new or changed layers of an image are downloaded, drastically reducing image pull times. Smaller base images inherently contain fewer layers and less data to transfer. Consolidating images reduces the number of independent downloads required.

3. Inefficient Caching Strategies

Diagnosis: Steps that involve dependency installation (e.g., npm install, bundle install, pip install) are taking a long time, even though you have caching configured.

Common Cause:

Cache Invalidation: Your cache is being invalidated too often due to overly broad cache keys. For example, caching based on %{revision} will invalidate the cache on every commit, defeating its purpose for dependency installs.
Large Cache Size: You’re caching too much, leading to slow upload and download times for the cache.
Incorrect Cache Key: The cache key doesn’t accurately reflect the dependencies, causing CircleCI to miss the cache when it should hit it, or hit it when it shouldn’t.

Diagnosis Command/Check:

Review the circleci/config.yml for your save_cache and restore_cache steps.
Check the cache keys being used. Are they specific enough to your dependencies (e.g., package-lock.json, Gemfile.lock)?
Look at the build logs to see if restore_cache is failing (cache miss) or if the cache is being saved/restored with very large files.

Fix:

Use Specific Cache Keys: Base your cache keys on the files that define your dependencies.

jobs:
  build:
    steps:
      - checkout
      - restore_cache:
          keys:

            - v1-dependencies-{{ checksum "package-lock.json" }}

            - v1-dependencies- # fallback
      - run: npm install
      - save_cache:

          key: v1-dependencies-{{ checksum "package-lock.json" }}

          paths:
            - node_modules

Here, {{ checksum "package-lock.json" }} creates a unique cache key based on the content of your lock file. If package-lock.json hasn’t changed, the cache will be hit.

Be Selective with Paths: Only cache the necessary directories. For example, cache node_modules for npm, vendor/bundle for Ruby, or ~/.cache/pip for Python, but avoid caching entire project directories.
Use Fallback Keys: Include a less specific fallback key (like v1-dependencies-) to ensure a cache is restored even if the exact checksum key misses, though this is less ideal for frequent updates.

Why it works: Using precise cache keys ensures that the cache is only restored when the dependencies haven’t changed, maximizing cache hits. Saving only necessary directories minimizes the amount of data that needs to be transferred, speeding up cache operations.

4. Overly Complex Workflows and Orbs

Diagnosis: The job itself might be simple, but the workflow it’s part of has many dependencies, or it’s using complex or poorly optimized Orbs.

Common Cause:

Unnecessary Parallelism/Dependencies: Jobs are configured to run sequentially when they could run in parallel, or depend on jobs that don’t need to complete first.
Inefficient Orb Usage: An Orb might be downloading large assets, running slow commands, or not configured optimally.
Large Artifacts: Jobs are generating very large artifacts that take a long time to upload.

Diagnosis Command/Check:

Examine your .circleci/config.yml workflow definition. Use the CircleCI UI’s workflow visualization to see the dependency graph.
Inspect the configuration of any Orbs you’re using. Check their documentation for performance-related options.
Review store_artifacts steps to see what’s being stored and its size.

Fix:

Optimize Workflow Dependencies: Re-evaluate your workflow. Can job-B run in parallel with job-A instead of waiting for it? Can you remove unnecessary job dependencies?
Choose Performant Orbs: Select Orbs that are well-maintained and known for their efficiency. If an Orb is slow, consider if you can replace its functionality with simpler, custom steps.
Limit Artifacts: Only store artifacts that are absolutely necessary for debugging. If you’re storing build outputs, consider if they can be deployed directly or stored in a more efficient object storage solution.

Why it works: Streamlining workflows reduces overall pipeline execution time by allowing tasks to run concurrently. Efficient Orbs minimize the overhead they introduce. Limiting artifact storage reduces I/O bottlenecks.

5. Inadequate Resources (Less Common for Standard Jobs)

Diagnosis: Even after optimizing code and dependencies, a specific job consistently runs slowly, and the CPU/memory usage in the CircleCI build logs seems maxed out.

Common Cause:

CPU-Bound Tasks: The job is performing heavy computation (e.g., compiling large C++ projects, complex data processing) that simply requires more CPU power than the default container provides.
Memory-Intensive Operations: The job needs more RAM than available, leading to excessive swapping and slow performance.

Diagnosis Command/Check:

Monitor CPU and memory usage within the build logs for the slow job.
If using Docker, you can inspect container resource limits.
Try running the job locally on a machine with more resources to see if performance improves dramatically.

Fix:

Upgrade to a Higher Resource Class: CircleCI offers different resource classes for its runners. You can specify a larger resource class in your config.yml for specific jobs.
```
jobs:
  build:
    resource_class: large # or xlarge, 2xlarge, etc.
    docker:
      - image: cimg/node:18.17.0
    steps:
      # ...
```
This allocates more CPU and RAM to the job’s execution environment.
Distribute Computation: If possible, break down the heavy computation into smaller tasks that can be processed in parallel across multiple jobs or even external distributed computing services.

Why it works: Providing more CPU and RAM directly addresses the bottleneck if the slowness is due to resource constraints, allowing the compute-bound tasks to complete much faster.

After implementing these fixes, monitor your CircleCI Insights dashboard again. You should see a noticeable decrease in the duration of your previously slow jobs. The next challenge you’ll likely encounter is optimizing the overall workflow to reduce idle time between jobs and ensuring consistent test reliability.