Thresholds turn your service-level objectives into pass/fail criteria. Put them in options.thresholds, both on built-in metrics and on custom ones you create for the part of a journey you care about:

import http from 'k6/http';
import { check } from 'k6';
import { Trend } from 'k6/metrics';

const checkoutDuration = new Trend('checkout_duration', true); // true: time values

export const options = {
  thresholds: {
    http_req_duration: ['p(95)<300', 'p(99)<800'],
    http_req_failed: ['rate<0.01'],
    checkout_duration: [{ threshold: 'p(95)<1000', abortOnFail: true, delayAbortEval: '30s' }],
    checks: ['rate>0.99'],
  },
};

export default function () {
  const res = http.post('https://api.example.com/v1/checkout', JSON.stringify({ cartId: 'demo' }), {
    headers: { 'Content-Type': 'application/json' },
  });
  checkoutDuration.add(res.timings.duration);
  check(res, { 'status is 200': (r) => r.status === 200 });
}

When any threshold fails, k6 finishes the run and exits with code 99, which fails the CI step without any extra scripting. abortOnFail stops the test early once a threshold is clearly lost, and delayAbortEval gives it time to warm up first. Remember that a failed check does not fail the run by itself: add a threshold on checks, as above, if it should. Set thresholds from your measured baseline and your SLOs, not from round numbers.

Sources: k6 thresholds, k6 custom metrics