Back to home

LaunchGate

A release verdict before your users see the release

Not an AI summary of charts, but a deterministic criterion: load-test results checked against your SLOs and baseline, with a GO / CONDITIONAL_GO / NO_GO verdict right in the pull request.

Why not just thresholds?

“Unless your verification process is mature, do not rely entirely on Pass/Fail results to guarantee the reliability of releases. Frequently, you'll encounter 'false positives' and 'true negatives' when testing with distinct types of load.”

The k6 documentation explicitly warns that static Pass/Fail thresholds in CI are noisy and prone to false alarms. LaunchGate turns raw metrics into an authoritative, noise-resistant release verdict (GO / CONDITIONAL_GO / NO_GO) evaluated against historical baselines.

Example report

What a verdict looks like

Demo data. This is how the report lands on a pull request after the k6 run.

service
checkout-api
release
v2.14.0 · PR #812
baseline
v2.13.2 (last 5 green runs)
checkobservedtargetseverityresult
p95 latency284 ms≤ 300 mscritical✓ pass
p99 latency612 ms≤ 800 mscritical✓ pass
error rate0.4%< 1%critical✓ pass
p95 vs baseline+3.1%≤ +10%critical✓ pass
saturation point1,850 RPS≥ 2,400 RPSminor! fail
  • hint: db pool exhausted at stage 4 (pool=20): raise pool or add read replica before peak
verdict:CONDITIONAL_GOCritical checks pass, one minor violation: merge allowed, fix before peak traffic.
How it works

1. SLOs live in your repo

slo.yaml defines p95/p99, error-rate, allowed regression vs baseline, and saturation thresholds. One source of truth for the test and the gate.

2. k6 on the pull request

Your CI runs k6 on every PR. The load generator is replaceable: LaunchGate reads the JSON summary, not terminal output.

3. A reproducible verdict

Same input, same verdict. A critical violation is NO_GO and blocks the merge; a minor one is CONDITIONAL_GO with a hint on what to fix.

Public Incident Teardown

GitHub 17.08 Outage (7h 47m): Why the Autoscaler Went Blind

A live LaunchGate validation report: why HPA watched host CPU (48%) instead of Istio sidecar concurrency limits, how client retries amplified traffic 10x, and how to verify your cluster in 1 hour.

Read Full Report →
How the setup closes

Three outcomes, no dead-end report

Team runs it alone

The gate, slo.yaml and k6 suites stay in your repo. No further paid engagement required.

Periodic review

Monthly review of the SLO budget and gate false positives.

Paid next step

Fractional Performance Engineer: monthly, cancel anytime, $9,000/mo.

CI Gate setup: 1–2 weeks, fixed $7,500. Details on /pricing