Skip to content
Gaugeline

DWGGL-240REV4Sheet01 / 08

Start free trial

§01Latency budgets for CI

Catch the 14 ms regression before it ships.

View 1Trace, POST /checkout, PR #4127Scale 5 u/msUnits ms
118 ms +14 POST /checkout auth cart.load db.query price render 0 50 100 ms main PR #4127 Budget 120 ms 1 2

Gaugeline replays two thousand recorded production requests against every pull request, compares each span with main and fails the check when a budget is crossed. One YAML file. Nothing new running in production.

01Median check time
4 min 10 s
02Requests per run
2,000
03False-positive rate
0.6 %
Start a 14-day trialRead the docs

§02How it works

Four minutes from push to a red check.

Everything runs in your CI. Production only ever sees a sidecar that reads.

DETAIL BCheck pipeline, schematicUnits ms
≈ 4 min Capture 2,000 requests Replay main + PR Compare Gate Report 1 comment 1 2 3 4 5

  1. 01 / 05

    1. Capture

    A sidecar samples real requests at the edge, strips personal data by schema and keeps a rolling set of two thousand.

    2,000 requests

  2. 02 / 05

    2. Replay

    Both builds run in identical containers on one host, interleaved request by request, so noise lands on both equally.

    main + PR

  3. 03 / 05

    3. Compare

    Every span is compared at p50, p95 and p99. A change is reported only when its confidence bound clears your threshold.

    99 % bound

  4. 04 / 05

    4. Gate

    Budgets live in gaugeline.yml next to your code. Cross one and the check fails; raise it in the same pull request and a reviewer sees why.

    p95 ≤ 120 ms

  5. 05 / 05

    5. Report

    One comment on the pull request: the span that moved, by how much, and the commit that moved it.

    1 comment

§03Configuration

The whole setup is one YAML file.

Budgets are reviewed like code because they are code. This is the file a new team commits on day one.

Listing Cgaugeline.yml19 lines
# gaugeline.ymlversion: 2capture:  requests: 2000  redact: [email, card, token]replay:  order: interleaved  baseline: mainbudgets:  - route: POST /checkout    p95: 120ms  - route: GET /search    p95: 80ms    p99: 200mscompare:  confidence: 0.99  min_change: 3msreport:  comment: on_regression

  1. Line 04

    Two thousand real requests

    Sampled at the edge by the sidecar. Personal fields are dropped by schema before anything is stored.

  2. Line 07

    Interleaved, never in sequence

    Main and the pull request answer the same request back to back on one host, so a noisy neighbour hits both.

  3. Line 11

    A budget per route

    Cross it and the check fails. Raise it in the same pull request and the reviewer sees the change in the diff.

  4. Line 16

    Only what it can prove

    A change is reported when its 99 % bound clears min_change. That is how false positives stay at 0.6 %.

§04Figures

Noise is what kills a latency check.

Most performance gates are switched off within a month because they cry wolf. These are Gaugeline's numbers across 1,140 repositories in September.

  1. 01False-positive rate

    0.6%

    Failed checks that the author later marked as noise.

  2. 02Smallest regression caught

    3ms

    At p95, from 2,000 requests, with a 99 % confidence bound.

  3. 03Median check time

    250s

    From the push to the status on the pull request.

  4. 04Repositories gated

    1,140

    Teams from four people to four hundred.

§05Notes

Questions we get in code review.

  1. Does it touch production?

    Only the capture sidecar does, and it only reads, adding under 0.2 ms at p99. Replays run in your CI, against your build.

  2. What about requests with side effects?

    Writes are replayed against a throwaway database snapshot taken at capture time. Outbound calls are answered from recorded responses.

  3. How is this different from a load test?

    A load test asks how much traffic you can take. Gaugeline asks whether this change made the same traffic slower, and by how much.

  4. Can I fail a check on purpose?

    Yes: lower a budget in gaugeline.yml and push. Most teams do this in their first hour to see the comment they will get.

§06Pricing

Priced per repository, not per seat.

Everyone on the team sees the checks. Every plan starts with fourteen days free, without a card.

  1. Item
    01
    Qty
    1 repo
    Rev
    4

    Team

    $49per repo / month

    For a service or two with one main branch.

    Bill of materials, Team
    PosQtyDescription
    012,000Recorded requests per run
    02AllPull requests and budgets
    032CI providers: GitHub, GitLab
    0430 dTrace retention
    Start a trial
  2. Item
    02
    Qty
    1 repo
    Rev
    4
    Note
    Recommended

    Scale

    $149per repo / month

    For teams that gate every service in a monorepo.

    Bill of materials, Scale
    PosQtyDescription
    0110,000Recorded requests per run
    02AllBudgets, scoped by path
    036CI providers, every one we support
    041SSO and audit log
    0590 dTrace retention
    Start a trial
  3. Item
    03
    Qty
    1 org
    Rev
    4

    Self-hosted

    From$12kper year

    Replay workers inside your own VPC.

    Bill of materials, Self-hosted
    PosQtyDescription
    011Everything in Scale
    021Air-gapped install in your VPC
    031Bucket in your own object storage
    041Named support engineer
    Talk to us

§07Start

Put a number on every pull request.

Fourteen days, every feature, no card. Most teams have their first budget failing on purpose within the hour.

Start a 14-day trialBook a walkthrough

Releasedfor productionRev 4 · 2026-10-30GL-240