# SLO-style thresholds: `slo(N%) < bound` reads as "N% of requests finish
# within the bound" — the way SLOs are written in the reliability doc, with no
# percentile translation in your head. slo(99%) < 300ms == p(99) < 300.
#
# Supported objectives match the fixed points the histogram summary carries:
# 50, 90, 95, 99, 99.9 (the % sign is optional). Bounds accept duration units
# (300ms, 1.5s) or plain milliseconds, and the classic `p(95)<500` syntax mixes in
# freely.
#
#   loadr run examples/46-slo-thresholds.yaml
name: slo-thresholds
description: latency SLOs as first-class pass/fail thresholds

defaults:
  http:
    base_url: https://httpbin.org
    timeout: 10s

scenarios:
  storefront:
    executor: constant-vus
    vus: 10
    duration: 1m
    flow:
      - request:
          name: browse
          url: /get
          checks:
            - { type: status, equals: 200 }
      - request:
          name: checkout
          method: POST
          url: /post
          body:
            json: { sku: "A-1", qty: 1 }
          checks:
            - { type: status, equals: 200 }

thresholds:
  # The service SLO: 99% of requests within 300ms, 99.9% within 1s.
  http_req_duration:
    - "slo(99%) < 300ms"
    - "slo(99.9%) < 1s"
  # A stricter per-endpoint SLO via a tag selector, mixed with expression syntax.
  "http_req_duration{name:checkout}":
    - "slo(95%) < 250ms"
    - "p(50)<150"
  # 99.9% availability, as an error-rate bound.
  http_req_failed: [ "rate<0.001" ]
