📐 har-to-slo

Your HAR file already knows your p95. You just haven't asked it yet.

Every time you record a HAR — from Playwright, Chrome DevTools, an API gateway export, or a browser session — you're capturing real latency measurements for every route in your app. har-to-slo reads those measurements, computes p95 baselines per route, and outputs a ready-to-use k6 thresholds {} block. Stop inventing SLO numbers. Derive them.

Not a HAR-to-k6-script converter. grafana/har-to-k6 replays traffic. har-to-slo reads the timings in that same file and turns them into statistically grounded SLO baselines. They complement each other — use both.

_{☝️ Real output from a 48-entry HAR. Six routes, all HTTP methods, zero configuration.}

---

The problem it solves

When you add a k6 thresholds {} block, you need a number:

"http_req_duration{url:/api/orders}": ["p(95)<???"],

Where does that number come from? Usually: a guess, a round number, or copied from another service. har-to-slo answers that question with measured data from your own traffic.

---

Install

# No install needed — run with npx
npx har-to-slo --input recording.har

---

Usage

# Basic — outputs k6 thresholds block to stdout
npx har-to-slo --input recording.har

# Tighter SLOs (1.2× p95 instead of default 1.5×)
npx har-to-slo --input recording.har --multiplier 1.2

# JSON — for CI pipelines and tooling integrations
npx har-to-slo --input recording.har --format json

# Write directly into your k6 script file
npx har-to-slo --input recording.har --output k6/thresholds.js

# With LLM rationale for each threshold (requires ANTHROPIC_API_KEY)
npx har-to-slo --input recording.har --explain

---

Supported sources

Source	Command	What it reads
har (default)	har-to-slo --input recording.har	HAR file timing data
k6	har-to-slo --source k6 --input summary.json	k6 --summary-export JSON
logs	har-to-slo --source logs --input nginx.log	nginx / ALB / NDJSON access logs
otel	har-to-slo --source otel --input traces.jsonl	OpenTelemetry trace JSONL export
prometheus	har-to-slo --source prometheus --url http://prom:9090 --query http_request_duration_seconds	Prometheus / Mimir HTTP API

Using with the Grafana stack

# From a k6 load test run
k6 run --summary-export summary.json load-test.js
har-to-slo --source k6 --input summary.json

# From Grafana Mimir (or any Prometheus)
har-to-slo --source prometheus \
  --url http://mimir.internal:9090 \
  --query http_request_duration_seconds \
  --range 30d

# From Grafana Tempo trace export (OTEL JSONL)
har-to-slo --source otel --input tempo-export.jsonl

---

How it works

HAR file
  └─ entry.time per request (real latency in ms)
       └─ collapse URLs: /users/123 → /users/{id}
            └─ group by METHOD + template
                 └─ trim top 5% outliers
                      └─ compute p95 per group
                           └─ threshold = Math.round(p95 × multiplier)
                                └─ emit k6 thresholds {} block

A HAR entry's .time field is the total wall-clock duration of that request as observed by the client. This is the same number your users experience. It's the right number for an SLO.

---

Output example

Given a HAR with requests to 6 routes:

// Auto-generated by har-to-slo
// https://github.com/aks-builds/har-to-slo

export const options = {
  thresholds: {
    // GET /api/v1/users/{id} — p95 baseline: 142ms (n=8, ×1.5)
    "http_req_duration{scenario:GET_/api/v1/users/_id_}": ["p(95)<213"],
    // GET /api/v1/products — p95 baseline: 250ms (n=8, ×1.5)
    "http_req_duration{scenario:GET_/api/v1/products}": ["p(95)<375"],
    // POST /api/v1/orders — p95 baseline: 610ms (n=8, ×1.5)
    "http_req_duration{scenario:POST_/api/v1/orders}": ["p(95)<915"],
  },
};

---

Using alongside grafana/har-to-k6

These tools do different things and work together:

# Step 1 — generate a k6 load test script from your HAR recording
npx har-to-k6 recording.har -o load-test.js

# Step 2 — generate statistically grounded thresholds for that script
npx har-to-slo --input recording.har --output thresholds.js

# Step 3 — merge thresholds.js into load-test.js

har-to-k6 asks: "what requests should my load test replay?" har-to-slo asks: "what latency should I fail the load test at?"

---

Options

Flag	Default	Description
--input, -i	(required)	Path to HAR file
--multiplier, -m	1.5	Threshold = p95 × multiplier
--format, -f	js	Output format: js or json
--output, -o	stdout	Write to file instead of stdout
--explain, -e	off	Annotate with Claude Haiku rationale (needs ANTHROPIC_API_KEY)

---

E2E test results

Dataset	Entries	Routes	Status
Small	5	3	✅
Medium	48	6	✅
Large	500	10 (with UUIDs)	✅

---

Claude Code Skill

A bundled Claude Code skill lets AI agents call har-to-slo during PR review to check whether load test thresholds are grounded in real data or invented.

---

License

MIT © aks-builds