Sure! There’s a global setting to do exactly this.
Go to the Settings page of your dashboard. In the Playback Options, you’ll see an option called Include error responses in response times.
This option is checked by default, meaning that error responses (at least HTTP 4xx/5xx and validation errors) are included in the response time metrics (average response times, maximum/minimum response times, and percentiles).
If you uncheck it, only successful responses with an HTTP 2xx/3xx status code and no validation errors will be included in these metrics.
Usually not! You’re better off finding the cause of the error responses and fixing that.
In most cases, an HTTP 4xx response status means something is wrong with your script. It’s probably trying to load a resource that doesn’t exist, or sending an unacceptable request to the server. Or maybe something has changed with the site or application since you created the script. Either way, it’s better to find and fix the source of these errors than to try to infer anything about response times in spite of them.
An HTTP 5xx response can mean different things. If it’s a 503, it means the site has become unavailable, and when it happens in connection with a load test, you’ll certainly want to fix that before proceeding.
However, there are edge cases when you might want to exclude these error responses. For example, a REST API often uses HTTP 404 to signify that no resource is available at that location, even though the request and the path structure is valid. If the error responses aren’t perceptible to the end user, you might be able to safely omit them from response time calculations.