Adding Load Tests to CI/CD with GitHub Actions

Unit tests verify correctness. Load tests verify your API still performs under concurrency after each change. Load Curl's CI/CD integration (Pro plan) lets you run tests from GitHub Actions, GitLab CI, or Jenkins and fail the pipeline when grades fall below your threshold.

Why load tests belong in CI

A refactor that adds one extra database round-trip might pass all functional tests while doubling p95 latency. Catching that in CI costs minutes; catching it in production costs customers.

Keep CI load tests short and focused:

• One or two critical endpoints per workflow
• Staging URLs with stable test data
• 3–5 minute runs with moderate concurrency
• Grade threshold of B or higher (adjust per team)

Prerequisites

1. Load Curl Pro organization with CI/CD enabled
2. API token stored as a GitHub secret (LOADCURL_API_TOKEN)
3. A saved test configuration ID or inline test definition
4. Staging environment that tolerates periodic load

Example GitHub Actions workflow

name: API load test

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

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

      - name: Run Load Curl test
        env:
          LOADCURL_API_TOKEN: ${{ secrets.LOADCURL_API_TOKEN }}
          LOADCURL_TEST_ID: ${{ vars.LOADCURL_STAGING_TEST_ID }}
        run: |
          npx @loadcurl/cli run \
            --test-id "$LOADCURL_TEST_ID" \
            --wait \
            --fail-below-grade B

      - name: Upload report artifact
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: load-test-report
          path: loadcurl-report.json

The CLI polls until the test completes, then exits non-zero if the grade is below B.

Secrets and environments

• Store tokens in GitHub Environments for production promotion workflows
• Use different LOADCURL_TEST_ID values for PR vs main — PRs might use lower concurrency
• Never commit tokens; rotate if leaked

Pull request comments

Teams often post the report card summary as a PR comment. Load Curl's API returns grade, p95, and error rate — enough for reviewers to see impact without opening the dashboard.

Avoiding flaky pipelines

• Pin concurrency and duration — changing variables every run makes trends meaningless
• Retry once on infra blips — staging occasionally restarts; a single retry reduces noise
• Exclude scheduled maintenance windows — or use workflow concurrency groups

GitLab CI and Jenkins

The same CLI works across providers. Replace the run step with your runner's script block and map secrets to LOADCURL_API_TOKEN.

When not to gate on load tests

Early prototypes, documentation-only PRs, and shared staging outages should not block merges blindly. Use workflow_dispatch for manual runs and required checks only on protected branches.

Get started

Upgrade to Pro, create a staging test in the dashboard, copy the test ID, and add the workflow above. Your next deploy will prove performance — not just green unit tests.