K6 Checks
You set up k6 checks by writing boolean rules that inspect HTTP responses during load tests. These rules check status codes, headers, or body text without stopping the test run. Teams often run load tests against staging or prod apps using broad service roles. If those roles have too much power, test scripts can read or write live data. How k6 checks work during a test run A load test sends many requests to an app at the same time. Network tools tell you if a server drops a request. They do n
Pull Request Security Checks: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up k6 checks by writing boolean rules that inspect HTTP responses during load tests. These rules check status codes, headers, or body text without stopping the test run. Teams often run load tests against staging or prod apps using broad service roles. If those roles have too much power, test scripts can read or write live data.
How k6 checks work during a test run
A load test sends many requests to an app at the same time. Network tools tell you if a server drops a request. They do not tell you if the app sent back the right data. An app under heavy load might return a normal status code with an empty body. You need a way to inspect the response payload while the test runs.
When you add k6 checks to a script, the tool tests each response against your rules. Each rule asks a true or false question about the response. One rule might ask if the status code equals two hundred. Another rule might ask if the response body holds a specific text string. The tool counts how many times each rule passes or fails across all virtual users.
A failed check does not stop the script or abort the test run. The virtual user keeps running the rest of the script and sends more requests. At the end of the run, the summary report shows the pass rate for each check. This design lets you see how often an app fails under stress without halting the load.
Combining checks with thresholds for pass or fail rules
Because checks do not fail a test on their own, build pipelines need extra rules. If half of your checks fail, the tool still exits with a success code. Your deployment pipeline will think the load test passed and push bad code to prod. Teams fix this by pairing checks with thresholds in the test options.
A threshold sets a minimum pass rate or a maximum response time for the whole run. You can link a threshold to a specific group of checks through tags. For example, you can require that ninety-nine percent of status checks pass during the run. If the pass rate drops below that mark, the threshold fails the test. The tool then returns a non-zero exit code and stops your deployment pipeline.
Pull Request Security Checks: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native load test setups solve and leave open
Checks and thresholds confirm that your app handles traffic and returns valid responses. They help teams catch slow queries and broken endpoints before users notice. Still, load test runners still need credentials and network paths to reach internal apps and databases. Teams often store static API keys or database passwords in runner secrets to run these tests.
This native setup decides which runner can log in, not what individual requests do in flight. A shared test role might have permission to run heavy write queries or read real user records. If a check fails and logs the raw response body, sensitive data can leak into build logs. Masking rewrites matched fields like emails, phone numbers, card numbers, and national IDs in results before logs save them.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Do k6 checks stop a test when a condition fails?
No, a failed check only records a failure metric and lets the test continue. To make a failed check return an error exit code, you must pair it with a threshold.
Can I check multiple conditions on a single HTTP response?
Yes, you can group multiple rules inside one check call for the same response. The tool tests each rule on its own and tracks separate pass rates for every condition.
Why do my load test logs show raw user data when checks fail?
Scripts often print the response body when a check fails so engineers can fix the bug. If the test hits an app with real data, those logs will capture unmasked fields like emails.