Fail the build on a performance regression
Catch the change that made it slower in the pull request, not in the incident.
Performance regressions are found late because nothing checks for them early. Correctness has tests that run on every push; speed usually has a dashboard somebody looks at after a complaint. The CI gate closes that gap: profile in the pipeline, compare against the baseline, and fail the build when it gets worse.
One binary, no dependencies
The agent is a single static Go binary with a zero-dependency build.
- Nothing to install into the build image
- No daemon, no sidecar, no service to keep up
- Runs the same on a laptop and on a runner
A gate, not a graph
The pipeline needs a pass or a fail, not something to look at.
- Compares a run against its baseline
- Exit code is the verdict
Findings on the pull request
The failure says what got slower, not just that something did.
- The regression is reported with its stacks
- Full report available for the failing run
Same analysis as an upload
The gate is not a lesser path — it is the same engine.
- Identical findings and evidence
- Report retained in history alongside manual uploads
Frequently asked questions
What do I add to my pipeline?
One step that runs the agent binary. It records or accepts a profile, submits it, and exits non-zero when the run regresses against its baseline.
Will noisy CI runners cause false failures?
Shared runners are noisy, which is exactly why the gate compares against a baseline from the same environment rather than an absolute threshold. A number that means anything has to be relative.
Is the agent open source?
The agent and the CI gate live in their own public repository, separate from the service. It is a small Go program with no third-party dependencies — the kind of thing you should be able to read before putting it in your build.
Upload a profile. Leave with a plan.
Free to start — 10MB recordings, full reports, no card.
Create a free account