In JMeter, what does ticking Ignore Status on a Response Assertion do to a 500 sample?

Ignore Status is the one control in a stock JMeter plan that can turn a red sample green, which makes it worth knowing precisely rather than by reputation. ## What the checkbox does In `ResponseAssertion.evaluateResponse(SampleResult response)` the very first statement is: ```java if (getAssumeSuccess()) { response.setSuccessful(true);// Allow testing of failure codes } ``` Only then does the method fetch the field to check and start matching patterns. The component reference says the same thing in words: *"When the Ignore Status checkbox is selected, the Response status is forced to successful before evaluating the Assertion."* Three facts follow: - The sampler's `200–399` verdict is **discarded**, not combined with anything. - Whatever the assertion decides afterwards is the whole verdict, through the usual `result.setSuccessful(result.isSuccessful() && !failed)` in `JMeterThread.processAssertion`. - Because the forced success is written onto the shared `SampleResult`, the manual warns to use the box on the first assertion under a sampler only. It is a property of the **Response Assertion** specifically. The Duration Assertion, Size Assertion, JSON Assertion and the rest have no equivalent; `Assertion.assume_success` appears nowhere else in the source. ## The legitimate use Ignore Status exists so that a plan can load-test an error path on purpose. If you want a sampler that hits an endpoint with a deliberately invalid payload and asserts that the service answers `400` with a machine-readable problem document, the status rule is in your way — it would mark every such sample failed. Tick Ignore Status, set *Field to Test* to `Response Code`, and match `400`. Now the sample fails when the service returns anything except the error you asked for, which is exactly the oracle you wanted. ## How it becomes a false green The misuse is almost always the same story, and it is how a run ends up **reporting zero errors while serving error pages**. A plan is noisy: a share of samplers return `401` because a token expires mid-run, and the report is full of red. Someone ticks Ignore Status to make the report readable, intending to come back to it. From that moment: 1. Every `401`, `500` and `503` on that sampler is forced to success before any pattern runs. 2. The assertion's pattern is usually something broad — a page title, a `<html` tag, a word that appears in the error template too — so it matches the error body as happily as the real one. 3. The run's error count falls to zero, and the response times now describe how fast the service returns errors. The setting has not hidden the errors from a listener; it has genuinely changed the verdict recorded in the results file, so nothing downstream can recover it. ## Reviewing for it Because the checkbox is a plain property in the plan file, it is greppable. A `.jmx` carrying it looks like this: - element `<ResponseAssertion ...>` - a `<boolProp name="Assertion.assume_success">true</boolProp>` line - an `<intProp name="Assertion.test_type">` value naming the matching rule - the patterns inside `<collectionProp name="Asserion.test_strings">` — the misspelling is JMeter's own and is stable So a review can ask a simple question of every plan in a repository: which samplers set `Assertion.assume_success` to `true`, and is each one deliberately testing a failure path? Any that are not are places where the plan has stopped reporting what the service did. ## The pattern still has to be strict Even where Ignore Status is correct, it shifts the entire burden onto the pattern list. `Contains` with a short, common string is not enough once the status is out of play — pick a string that only the intended reply carries, or assert on `Response Code` directly. The rule of thumb is that after ticking the box you should be able to describe, in one sentence, the exact reply that passes; if you cannot, the assertion is not carrying the weight the status rule used to.