Docs

Stress Testing (K6)

What this screen is for

Stress Testing runs K6 load tests against your services and keeps the results, so “it got slow” becomes a number you can compare against last month.

Before you start

To do this You need
Open Stress Testing the K6 access permission

Opening it

Tools › Stress Testing.

Direct URL: /k6-stress-testing

📸 Screenshot Placeholder: The K6 stress testing page with one completed run. Mark: (1) the run list, (2) a run status, (3) the results view, (4) the action that starts a new run.

What is Stress Testing?

Stress Testing is a tool integrated into Fenwave based on K6 that allows you to test the performance and resilience of your applications under load.

Accessing Stress Testing

  1. Click on Tools in the sidebar
  2. Select Stress Testing

Main Features

Test Types

Type Description Use Case
Load Test Standard load test Validate normal performance
Stress Test Stress test Find limits
Spike Test Sudden spikes Test resilience
Soak Test Endurance test Detect memory leaks

Collected Metrics

  • Response Time: p50, p90, p95, p99
  • Throughput: Requests per second
  • Error Rate: % of failed requests
  • Concurrency: Active virtual users

Usage

Create a Test

  1. Click on Create Test
  2. Configure parameters:
// K6 Configuration
export const options = {
  stages: [
    { duration: '1m', target: 10 }, // Ramp up to 10 VUs
    { duration: '3m', target: 10 }, // Stay
    { duration: '1m', target: 50 }, // Ramp up to 50 VUs
    { duration: '3m', target: 50 }, // Stay
    { duration: '1m', target: 0 }, // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'], // 95% < 500ms
    http_req_failed: ['rate<0.01'], // < 1% errors
  },
};

Define Scenarios

Create realistic scenarios:

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

export default function () {
  // Homepage
  let res = http.get('https://api.example.com/');
  check(res, {
    'status is 200': r => r.status === 200,
    'response time < 500ms': r => r.timings.duration < 500,
  });

  sleep(1);

  // API endpoint
  res = http.get('https://api.example.com/users');
  check(res, {
    'users loaded': r => r.json().length > 0,
  });
}

Run the Test

  1. Select the target environment (Dev/Staging only)
  2. Click on Run Test
  3. Monitor metrics in real-time

Interpreting Results

Real-Time Dashboard

During execution, visualize:

  • Response time graph
  • Number of active VUs
  • Error rate
  • Throughput

Final Report

After the test, consult:

  • Summary: Overview of performance
  • Details: Metrics per endpoint
  • Errors: List of errors encountered
  • Recommendations: Improvement suggestions

Performance Thresholds

Metric Good Acceptable Needs Work
p95 latency < 200ms < 500ms > 500ms
Error rate < 0.1% < 1% > 1%
Throughput > target = target < target

Best Practices

Preparation

  1. Test in staging: Never in production
  2. Isolate environment: Avoid interference
  3. Realistic data: Use representative test data
  4. Baseline: Establish reference before changes

During the Test

  1. Monitor resources: CPU, memory, I/O
  2. Logs: Check application logs
  3. Don’t interrupt: Let the test complete

After the Test

  1. Analyze results: Identify bottlenecks
  2. Document: Keep reports
  3. Compare: With previous tests
  4. Plan: Necessary optimizations

CI/CD Integration

Add performance tests to your pipeline:

# GitHub Actions
performance-test:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - name: Run K6 test
      uses: grafana/k6-action@v0.3.0
      with:
        filename: tests/performance/load-test.js

Scenario

Finding where a service falls over, before your users do.

  1. Confirm the service is correct first. Load testing something with a bug measures the bug.
  2. Run against staging, not production — and tell whoever shares staging, because you are about to make it slow for them.
  3. Start well below the load you expect. A first run at peak tells you only that it broke, not where.
  4. Increase until something degrades, and note what degrades first — latency, error rate, or a resource ceiling. That is the finding; the number it happened at is secondary.
  5. Cross-check Environment Detail › Metrics. A failure at a memory limit is a sizing problem, not a code problem, and the fix belongs in Resource Optimization.
  6. Save the run. A load test with nothing to compare against is a single data point, and single data points do not show trends.

When it doesn’t work

Symptom Cause How to check Fix
Stress Testing is not in the submenu Missing the K6 access permission Access Explorer Ask for a role granting it
A run fails immediately The target is unreachable from the runner The run output Check the target URL and network path
Results look implausibly good The load never actually reached the service The run output and target Verify the target; check for a cache in front
The environment degraded for others Staging is shared — Announce load tests in advance

Next