cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Can a synthetic process all requests instead of failing and stopping on the first failed request?

sivart_89
Advisor

I have a customer that is wanting to hit 60 endpoints with an HTTP synthetic monitor. With the current state the synthetic will stop upon the first failed request, resulting in subsequent requests not being tested. Is the only solution for this to create 60 different synthetics, 1 for each endpoint? I'm essentially wanting to do the below steps. Is it possible to use custom js in the synthetic during maybe the post execution step? If so anyone know what this will look like?

- Have 1 synthetic with all 60 endpoints
- The synthetic will continue upon failure of any request and process all subsequent requests
- Upon finishing it the synthetic will fail and create a problem only if there is 1 or more failed requests. The problem card ideally should list all failed requests so you know all that failed, not just mention only 1 request and not the remaining failures

6 REPLIES 6

AntonPineiro
DynaMight Guru
DynaMight Guru

Hi,

It those HTTP request are not related each other, I would create 60 Synthetics monitors.

Best regards

❤️ Emacs ❤️ Vim ❤️ Bash ❤️ Perl

They are all related to each other and the same team owns / uses the endpoints.

Hi,

It means, if information to next request depends of information of previous one. If not, I would split them.

Best regards

❤️ Emacs ❤️ Vim ❤️ Bash ❤️ Perl

There is no reason why we would not want to process (test subsequent requests) if a request fails. Rather than have 60 synthetics and numerous tickets if multiple synthetics fail, having the 1 synthetic process all of them and having 1 single problem is preferrable and makes the most sense I believe for this app team. We can go the route of creating multiple synthetics if needed, I'm just trying to understand if it is even possible with custom js and what that would look like.

I agree with Anton, if the requests are not related to each other, the best practice would be to have separate monitors for each requests. These can then be grouped together using tags etc but you would then see separate metrics and problems for each monitor rather than 1 monitor or problem that you then need to dig into to find which requests failed. 

That said, if you would prefer to have all your requests in one monitor and then work out afterwards which requests are a problem, you can use the suggested method here

Synthetic SME and community advocate.

Thank you @HannahM. The suggested method noted is something we may pursue further. Either way, it is good to know of the possibilities.

Featured Posts