Skip to content
Latchkey

Load test thresholds misconfigured: gate never fires in CI

A threshold or assertion that references a metric name that never emits, or is simply missing, means the gate can never fail. The job goes green regardless of performance, giving false confidence that the load test is protecting you.

What this error means

The load test always passes even when latency or error rate is clearly bad, because the threshold names a nonexistent metric or no assertion is defined at all.

Load test
# k6: threshold on a metric that never emits -> never evaluated -> always "passes"
thresholds: { htp_req_duration: ['p(95)<500'] }  // typo: htp_req_duration

Common causes

A metric name typo or wrong tag

A threshold keyed on a misspelled metric or an unused tag is never evaluated, so it can never fail the run.

No assertion/threshold defined at all

Without any threshold (k6) or assertion (Gatling), the tool exits 0 regardless of latency or error rate.

How to fix it

Assert against real, emitted metrics

  1. Use exact built-in metric names (http_req_duration, http_req_failed).
  2. Confirm the metric appears in the summary so the threshold is evaluated.
  3. Add at least one latency and one error-rate gate.
script.js
thresholds: {
  http_req_duration: ['p(95)<500'],
  http_req_failed: ['rate<0.01'],
},

Define a Gatling assertion so the build can fail

Add explicit assertions so a regression produces a non-zero exit.

LoadSimulation.scala
setUp(scn.injectOpen(rampUsers(100).during(30)))
  .assertions(global.responseTime.percentile3.lt(500), global.failedRequests.percent.lt(1));

How to prevent it

  • Reference exact built-in metric names in thresholds.
  • Always define at least one latency and one error-rate gate.
  • Verify the threshold shows as evaluated in the summary output.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →