k6 Workload Execution and static Gzip HTML Report Generation on Windows

Once you design a modular performance testing framework, you need to execute it and capture test results. If you only look at terminal printouts during execution, you miss out on high-fidelity telemetry distributions. You need a way to watch metrics live and archive detailed HTML reports that you can share with developers. Fortunately, the embedded k6 web dashboard handles this easily, providing real-time Server-Sent Events (SSE) streaming and automated compressed HTML exporting.

Let us look at how to run your modular framework on Windows, configure live dashboards, export gzip compressed reports, and review essential performance engineering best practices.

Executing Framework Workloads in PowerShell

Because Windows PowerShell handles session variables statefully, you can configure your parameters globally and execute your test suite cleanly. Here is the operational execution script to run your test suite and export a compressed, self-contained report:

# Set configuration parameters for the PowerShell session
$env:CONFIG_PATH="./config/average-load.json"
$env:BASE_URL="https://quickpizza.grafana.com"
$env:K6_WEB_DASHBOARD="true"
$env:K6_WEB_DASHBOARD_PORT="-1" # Headless mode, ideal for automated pipeline runs
$env:K6_WEB_DASHBOARD_EXPORT="reports/load-test-report.html.gz"

# Execute k6 workload using your main orchestrator script
k6 run .\main.js

Visualizing and Sharing Your Results

Real-time Monitoring: If you want to watch the metrics update live in a browser as the test runs, set the port environment variable to a positive value in your PowerShell terminal before executing the test:

$env:K6_WEB_DASHBOARD_PORT="5665"

You can then open http://localhost:5665 in any web browser to see real-time throughput, error rates, and latency distributions as they happen.

Gzip Compression: Because our export filename ends with the .gz extension, k6's internal reporting engine automatically compresses the static HTML report using gzip. This drastically reduces file size, making it highly compact.

Offline Sharing: Extracting the exported archive yields a fully self-contained, highly interactive, and responsive HTML report. Because there are no external resource dependencies, you can open it offline or attach it directly to your CI/CD pipeline runs for historical reference.

Critical Best Practices for Windows Operations

When running load tests on Windows, keep these three performance engineering rules in mind to prevent system errors and skewed metrics:

Avoid sleep() inside Open Workloads: When using arrival-rate executors (open-loop models), k6 handles iteration scheduling dynamically. Adding manual sleep() statements inside these scenarios disrupts the Go runtime scheduler, introducing scheduling drift and corrupting your metrics.
Size a High VU Ceiling (maxVUs): Always allocate a high maxVUs headroom ceiling in your scenarios. If your system encounters a latency spike and you do not have enough pre-allocated VU headroom, k6 will begin dropping iterations, reintroducing coordinated omission and corrupting your results.
Use Unix-Style Forward Slashes: Even though Windows utilizes backslashes (\) for filesystem paths, k6's embedded JavaScript virtual machine runs in an isolated Go sandbox that expects standard Unix-style forward slashes (/) for all module imports (such as import { auth } from './helpers/auth.js').

By establishing PowerShell script templates, leveraging gzip compression, and adhering to pathing and pacing best practices, you can run high-precision tests reliably on Windows.

To see how to clean install k6 on Windows, read Installing k6 on Windows: WinGet, Chocolatey, and Manual Path Automation. If you want to review shell scoping details, see Windows Environment Variables: Handling State in PowerShell and CMD for k6. To learn how to compile custom database-enabled binaries locally, check out Building custom k6.exe Binaries on Windows using xk6.

k6.wiki