sla-defaults.md

SLA Defaults & Threshold Recommendations

Default SLA by Profile

Profile	p95 Latency	p99 Latency	Error Rate	Check Success
minimal	<800ms	<1440ms	<2%	>95%
standard	<500ms	<900ms	<1%	>95%
aggressive	<300ms	<700ms	<0.5%	>99%

Exploratory Suggested SLA Policy

When the user does not know the SLA but gives a concrete goal such as concurrency, throughput, duration, or named business flows:

1. Reuse only the documented profile defaults from this file.
2. Emit the result as suggested_sla, never as a confirmed SLA.
3. Prefer a single suggested SLA when the request clearly maps to one profile.
4. Prefer multiple suggested SLA candidates only when the request is exploratory enough to justify a comparison, for example standard vs aggressive for a sustained backend load goal.
5. If the user provides a placeholder threshold such as "around p95<700ms", keep that as user input and supplement only the missing dimensions from the matching profile.

Example exploratory output shape:

suggested_sla:
  - profile: standard
    thresholds: p95<500ms,p99<900ms,error<1%,checks>95%
    reason: sustained validation goal with no explicit SLA
  - profile: aggressive
    thresholds: p95<300ms,p99<700ms,error<0.5%,checks>99%
    reason: stricter candidate for core backend flows under elevated concurrency

Parsing Examples

Input: p95<400ms,p99<900ms,error<1%

Output:

{
  http_req_duration: ['p(95)<400', 'p(99)<900'],
  http_req_failed: ['rate<0.01'],
  checks: ['rate>0.95']
}

Input: p95<2s (with inference)

Output:

{
  http_req_duration: ['p(95)<2000', 'p(99)<3600'],  // p99 = p95 * 1.8
  http_req_failed: ['rate<0.01'],
  checks: ['rate>0.95']
}

Input: p95<500ms AND p99<900ms AND error<1% (explicit AND)

Output:

{
  http_req_duration: ['p(95)<500', 'p(99)<900'],
  http_req_failed: ['rate<0.01'],
  checks: ['rate>0.95']
}

Input: p95<300ms AND p95>50ms (range constraint)

Output:

{
  http_req_duration: ['p(95)<300', 'p(95)>50'],  // Multiple conditions on same metric
  http_req_failed: ['rate<0.01'],               // defaults added from profile
  checks: ['rate>0.95']                         // defaults added from profile
}

⚠️ IMPORTANT: Note on p99 Inference: The p99 = p95 * 1.8 formula is an empirical heuristic based on common latency distribution patterns from real-world systems. This is not an official k6 standard or universally accepted performance engineering rule.

When to use: Use this approximation only as a starting point in development or testing environments when p99 values are not explicitly measured.

When NOT to use:

• Always replace with actual measured p99 values from production systems before deployment
• Do not assume this ratio applies to your specific application or infrastructure
• Conduct empirical testing under realistic load to validate your SLA thresholds

How to measure real p99: Run a baseline test in production (or staging if available), collect response time data, and calculate the actual 99th percentile from your metrics.

Protocol-Specific Metrics

HTTP

• http_req_duration - Total request time
• http_req_waiting - Time to first byte
• http_req_connecting - TCP connection time
• http_req_failed - Requests marked as failed by k6 according to expected status criteria (by default, responses outside 2xx/3xx) and network/transport errors

gRPC

• grpc_req_duration - Total RPC time
• grpc_req_failed - Failed RPCs

Browser

• browser_web_vital_fcp - First Contentful Paint
• browser_web_vital_lcp - Largest Contentful Paint
• browser_web_vital_cls - Cumulative Layout Shift