How Flood determines errors

How to customize the errors that Flood reports in the dashboard

You may have seen the errors that Flood displays per transaction and wondered how Flood knows whether a response was an error or not. Some of those errors are set programmatically in your script. For example, if you set up an assertion in your script to look for an element that isn't found, Flood will mark these transactions as errors.

If you don't have assertions, however, Flood would not report errors. This is why it's good practice to add assertions for actions on your script. For instance, when navigating to a home page, be sure to include an assertion or verification that a particular element or text on the page is found. This could be something like "Welcome" or the presence of a login button. That way, you'll know for sure whether the expected page was returned.

In addition, for protocol-based tools like JMeter and Gatling, Flood also looks at the HTTP response codes that are returned by the server. All HTTP 4xx and 5xx responses are automatically flagged as errors.

So what if you want Flood to recognize another HTTP response code as an error, such as an HTTP 304 "Not Modified"?

You can modify your load test script to specifically look for this response and fail transactions that receive this response. Let's go over an example of how to do this in JMeter.

You could do this quite easily by adding a Response Assertion to the request.​​

This will cause JMeter to fail that request if it receives an HTTP 304 response. This is then passed on to Flood so that it shows up as an error on your dashboard.

Last updated