Infrastructure Testing for Real-Time SLA and SLO Compliance

Turn an SLO into a test that can fail

An SLO is a promise about latency and availability at a given load. Monitoring tells you after the fact whether you kept it; a load test tells you before a release whether you can. This template holds your expected peak for thirty minutes and applies the SLO numbers as pass/fail thresholds, so a release that would burn the error budget fails the run instead of the quarter.

Configuration

Run this templateOpens the cloud test form with these values filled in. Free plan runs it at the free user limit; sign in or create a free account first.

The button prefills users, duration and ramp-up. Add the endpoints, then set the thresholds on the test from your SLO (the table below shows the mapping) and start.

What to read in the results

• p95 and p99 over the whole run. The Overview tab gives the run-wide percentiles from every sample; those are the numbers to compare to the objective, not the per-minute values.
• Error rate over time. The Errors tab plots errors per second. A steady 0.1% burns the budget slowly; a two-minute burst to 5% burns it in one go and points at a periodic job or a deploy.
• Per-endpoint breakdown. A run-wide pass can hide one endpoint that fails its share of the objective; filter by request to check the ones the SLO names.

Pass/fail thresholds for this template

Saved on the test, these thresholds make every run a yes or no against the SLO, and the verdict API lets the release pipeline read that answer.

The same scenario as a k6 script

As a k6 script, with the SLO written as k6 thresholds so the same numbers fail the run locally and in the cloud.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [{ duration: '2m', target: 400 }, { duration: '28m', target: 400 }],
  thresholds: {
    http_req_duration: ['p(95)<300', 'p(99)<800'],   // latency SLO
    http_req_failed: ['rate<0.001'],                  // 99.9% availability
    http_reqs: ['rate>250'],                          // the load the SLO is stated at
  },
};

const BASE = 'https://api.example.com';
const mix = [['/items', 0.6], ['/items/42', 0.3], ['/cart', 0.1]];

export default function () {
  const r = Math.random(); let acc = 0; let path = mix[0][0];
  for (const [p, w] of mix) { acc += w; if (r <= acc) { path = p; break; } }
  check(http.get(BASE + path), { 'ok': (res) => res.status === 200 });
  sleep(1);
}

When to run it

• Before every release as a gate, through the GitHub Action or the verdict API.
• When the SLO changes so the test and the promise stay the same numbers.
• After an incident to confirm the fix holds at peak, not just at the moment.

FAQ on SLO load testing

My SLO is monthly. How does a 30-minute test relate to it?

The test checks that the service meets the objective at peak load, which is when budgets burn fastest. It cannot replace monitoring over the month, but a release that fails at peak will not pass the month.

Should the test use p95 or p99?

Use what the SLO states. Set both thresholds if the objective names both; the analysis API exposes p50, p90, p95 and p99 for every run.

The throughput threshold failed but latency passed. Is that a pass?

No. If the run did not reach the load the SLO is defined at, the latency numbers do not prove anything. Fix the think time or user count so throughput matches, then read latency.

Can I automate this?

Yes. Save the test with thresholds, run it from CI with the GitHub Action or the API, and read the verdict; the analysis API returns the percentiles if you want to post them into the release notes.