Assertions and Checks

Inspect script-defined assertions and checks captured during a protocol load test, drill into individual failures, and use assertion counts as test thresholds.

The Assertions tab (for JMeter) or Checks tab (for k6) lists every script-defined assertion evaluated during your run. Assertions verify that your API behaved as expected, for example, that a response code was 200, a JSON field existed, or response time stayed under a threshold, and let you spot regressions without combing through raw logs.

Assertions are auto-detected from your script, so no project setting changes are required.

Where to find assertions

• API-only (protocol) tests: open a completed test run and look for the Assertions tab (JMeter) or Checks tab (k6) on the report.
• Hybrid tests: open the run and go to the Tests tab. The Assertions sub-tab lists API assertions; the Browser Tests sub-tab lists browser test cases.

Assertion fields

Each row on the Assertions sub-tab includes the following fields:

Field	Description
Name	The label defined in your script (for example, Status is 200).
Pass Count	Number of times the assertion passed across all virtual users.
Fail Count	Number of times the assertion failed across all virtual users.
Failed %	Percentage of total assertion executions that failed.
Failure Message	A summary of why the assertion failed (for example, “expected status 200, got 404”).
First Occurrence	The timestamp of when this assertion first failed during the test.

Use assertions to debug a run

The Assertions tab is the fastest way to move from “something failed” to “this specific assertion failed under this load”:

• Quick failure overview: scan the Failed % column to identify which assertions had the highest failure rates.
• Failure context: read the Failure Message to see why the assertion failed (for example, “expected status 200, got 404”).
• Correlation with load: compare the First Occurrence timestamp across assertions to see if failures clustered at a specific point in the test, correlating with load spikes.
• Failure drill-down: click View details on a failed assertion to inspect the Response Code Distribution and Response Body to understand what the API returned.

Drill into an assertion

Select any row or click View details to open the per-assertion drill-in view. This view shows:

• Response Code Distribution: a breakdown of HTTP response codes received for this assertion, including the code, count, description, and first occurrence timestamp.
• Response Body (when enabled): the captured response body for requests, when Capture response details is enabled on the test. This helps you understand what the API returned and why the assertion failed.

Use assertions to set test thresholds

You can use assertion outcomes as a pass/fail gate for the overall test. For example, you can set a threshold that fails the run if total assertion failures exceed a limit. To configure this, see Set thresholds.

k6 vs JMeter terminology

• k6: assertions are called Checks, and the sub-tab reads “Checks”.
• JMeter: assertions are called Assertions, and the sub-tab reads “Assertions”.

Both surfaces show the same fields and behavior (no setup difference, no separate enablement).

Related tabs

• Requests: per-endpoint latency and throughput.
• Errors: aggregated error breakdown.
• Logs: runtime log output per load generator.