CI Too Slow, Nobody Watches | 7 Strategies to Speed Up GitHub Actions and pytest

“Can’t wait for CI to finish.” “It’ll pass anyway.” — When CI takes too long, teams stop waiting and stop watching. This article explains how slow CI quietly destroys engineering culture, and walks through 7 concrete strategies to speed it up: pytest-xdist parallelization, stage splitting, caching, mocking, and more.

CI does more damage when it’s too slow than when it’s broken. A CI that fails in 3 minutes and a CI that fails in 30 minutes both catch the same bug — but they have completely different effects on the team.

“Is CI done?” “Still running. Just merge it for now.” — Once that conversation happens even once, the CI speed problem has already become a culture problem.

Unlike flaky tests, slow CI doesn’t break anything. It just quietly, gradually erodes the culture of checking CI at all. This article covers the collapse process that slow CI triggers — and the concrete strategies to stop it.

How Slow CI Leads to “Nobody Watches” Culture

7 Root Causes of Slow CI

Leaving CI as “just slow somehow” means it never gets fixed. Identifying which root cause is driving the slowness is the first step to making real improvements.

Fix ①: Parallelize with pytest-xdist

The highest-impact fix. pytest-xdist distributes tests across multiple CPU cores. For suites with 100+ tests, it commonly cuts execution time by 2–4x.

# Install
# pip install pytest-xdist

# Local: auto-detect CPU count and run in parallel
pytest tests/ -n auto

# GitHub Actions: specify worker count explicitly
pytest tests/ -n 4

# For CI-only activation (recommended — avoids conflicts with local debugging)
# Set in GitHub Actions step, not in pytest.ini:
#   run: pytest tests/ -n auto
#
# ⚠️ Adding -n auto to pytest.ini addopts causes issues with:
# VSCode Test Explorer, debugger, coverage measurement, flaky investigation

Fix ②: Split CI into Stages for Early Feedback

“Nothing to learn until all tests finish” is a design that has a ceiling regardless of how fast it runs. Splitting into unit → integration → E2E stages means bugs surface at the earliest possible point.

# GitHub Actions stage split example (.github/workflows/test.yml)
# Note: for large projects, consider reusable workflows or composite actions
# to avoid repeating the setup steps below in every job.
name: CI Pipeline

on: [push, pull_request]

jobs:
  # Stage 1: unit tests (target: under 1 minute)
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
          cache: "pip"              # built-in pip cache — no separate cache step needed
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run unit tests
        run: pytest tests/unit/ -n auto --tb=short

  # Stage 2: integration tests (target: under 3 minutes)
  # runs only if unit tests pass
  integration-tests:
    needs: unit-tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
          cache: "pip"
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run integration tests
        run: pytest tests/integration/ -n auto

  # Stage 3: E2E tests (target: under 5 minutes)
  # runs only if integration tests pass
  e2e-tests:
    needs: integration-tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
          cache: "pip"
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Install Playwright browsers
        run: playwright install chromium --with-deps
      - name: Run E2E tests
        run: pytest tests/e2e/ -n 2

Fix ③: Cache Dependencies to Skip Reinstalls

Running pip install from scratch every run can cost 2–5 minutes by itself. When dependencies haven’t changed, caching skips the install entirely.

# GitHub Actions caching example

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # ✅ Option A: built-in pip cache via setup-python (simpler)
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
          cache: "pip"             # invalidates when requirements.txt changes

      - name: Install dependencies
        run: pip install -r requirements.txt

      # ✅ Option B: manual cache with actions/cache (more control)
      - name: Cache pip packages
        uses: actions/cache@v4
        with:
          path: ~/.cache/pip
          key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
          restore-keys: |
            ${{ runner.os }}-pip-

      # ✅ Cache Playwright browser binaries
      - name: Cache Playwright browsers
        uses: actions/cache@v4
        with:
          path: ~/.cache/ms-playwright
          key: playwright-${{ hashFiles('requirements.txt') }}

      - name: Install Playwright browsers (only when cache misses)
        run: playwright install chromium --with-deps

Fix ④: Mock External I/O to Remove Wait Time

Tests that hit real DBs, external APIs, or email services add network latency and third-party response time as a CI bottleneck.

from unittest.mock import patch, MagicMock
import requests
import pytest

from sqlalchemy import create_engine
from sqlalchemy.orm import Session, declarative_base

# Base definition (in real projects, this lives in a models file)
# from sqlalchemy.orm import declarative_base
# Base = declarative_base()
Base = declarative_base()

# ❌ Slow: calls a real external API every time
def test_send_notification():
    result = requests.post(
        "https://api.slack.com/api/chat.postMessage",
        json={"channel": "#test", "text": "Test complete"}
    )
    assert result.status_code == 200
    # 200–500ms per network round-trip

# ✅ Fast: mock the external API — returns instantly
@patch("requests.post")
def test_send_notification_fast(mock_post):
    mock_post.return_value = MagicMock(status_code=200)
    result = requests.post(
        "https://api.slack.com/api/chat.postMessage",
        json={"channel": "#test", "text": "Test complete"}
    )
    assert result.status_code == 200
    # Under 1ms — no network involved

# ✅ Use an in-memory DB fixture instead of a real database
@pytest.fixture
def db_session():
    """Fast DB fixture using SQLite in-memory database"""
    engine = create_engine("sqlite:///:memory:")
    Base.metadata.create_all(engine)
    with Session(engine) as session:
        yield session
    # Automatically closes and rolls back when the with block exits

Fix ⑤: Replace time.sleep with Explicit Waits

If 100 tests each have one time.sleep(2), that’s over 3 minutes of fixed waste. Sleep is also a primary cause of flakiness — it’s the first thing to clean up from a CI speed perspective.

# Find all time.sleep usage (grep -R avoids matching asyncio.sleep or page.wait_for_timeout)
# grep -R "time.sleep(" ./tests

# ❌ Slow: fixed wait — always waits the full duration
import time
time.sleep(3)
driver.find_element(By.ID, "result").click()

# ✅ Fast: wait only until the condition is met
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 10)
element = wait.until(EC.element_to_be_clickable((By.ID, "result")))
element.click()
# Executes the instant the element is ready — average 0.3s instead of 3s

Fix ⑥: Profile and Audit Slow Tests

“We need all of them” without a regular audit leads to CI bloat. Profiling for the slowest 10–20 tests immediately surfaces the highest-value cleanup targets.

# pytest built-in feature — no additional plugin required
pytest tests/ --durations=20

# Recommended: only show tests that take 1 second or more (reduce noise)
pytest tests/ --durations=20 --durations-min=1.0

# Example output:
# 15.23s call  tests/e2e/test_checkout.py::test_full_purchase_flow
#  8.91s call  tests/e2e/test_login.py::test_login_with_mfa
#  6.44s call  tests/integration/test_report.py::test_generate_pdf_report
#  3.12s call  tests/unit/test_user.py::test_create_user  ← investigate: unit test over 3s

# ❌ Warning patterns:
# - Unit test taking 3+ seconds → external I/O may have leaked in
# - E2E test taking 20+ seconds → scope may be too broad
# - Multiple tests that are minor variations of the same scenario → consolidate with parametrize

Fix ⑦: Fix the Inverted Test Pyramid

When CI is fundamentally slow, the root cause is often an inverted test pyramid — E2E tests keep accumulating while unit and integration tests stay thin.

Act Before It Collapses: Early Warning Checklist

3 or more matching items means it’s time to start improving now.

FAQ

CI exists to protect code quality — but when it takes too long, it becomes something nobody waits for. A technical problem silently becomes a cultural one. Measure your current execution time today, and make one improvement. A team with a 5-minute CI and a team with a 30-minute CI will look very different a year from now.