Successful Synthetics Test if Error is Received

I have a need to run a lightweight test on a specific subnet to validate that it is isolated from our internal network; in other words, the the test is SUCCESSFUL if a DNS error or a timeout is received.

I have created the test and validated that the monitor fails as expected. My question is, is there a way that I can set the test to SUCCESSFUL on a DNS error or timeout and UNSUCCESSFUL under any other conditions (e.g., if any HTTP code is received back, even a 4xx or 5xx, it indicates that the test is communicating with the server and should therefore be a failure).

Can this be done and, if so, how?

Hi @DougR,

Are you using a lightweight YAML-based monitor or a scripted browser based monitor written with Playwright?

It's not something I've done myself, but I wonder if wrapping the appropriate call in a try/catch to catch the timeout error and assert true in Playwright would work? Have you tried that?

I'm using a lightweight test. I didn't think about creating a journey and using a try/except.

Thanks for confirming. For the lightweight monitor have you tried adding the 4xx and 5xx response codes to the Response checks option under Advanced options:

I have tried a test overriding the codes with 4xx codes and it does seem to change the failure to a passing test:

You are absolutely right that by default 4xx and 5xx response codes are treated as a failure, but you can override the codes here.

Let me know if that solves your issue.

Thanks - I thought of that as well, but it won't work for this use case.

In my use case, a DNS failure or a timeout indicate that the test is running as expected. The network I'm testing is an external-facing network that should be totally isolated from our internal network; there should be no route to the internal network and it should not be able to perform a DNS lookup for a host on our internal network. If it returns an HTTP code, that means that the monitor is able to reach the internal server and the network is not isolated, so the test has failed.

If there's not an easy way to do this with a lightweight test, then my best bet is probably to use a journey with a try/except block as you suggested earlier.


@DougR if i understand correctly, what you are saying is we should consider the error as a success essentially, some sort of negate: true option in monitor configuration. Where if monitor is down, we should consider it as up, we have even internally have had this kind of use- case, where essentially we are monitoring access to assets, and all those monitors appears down in UI. But our SRE team has been living with that :slight_smile:

i think it can be a nice enhancement request.

1 Like

@shahzad31 - That is exactly what I'm trying to accomplish, and you're right, that would be an awesome enhancement. Where does an enhancement request get submitted for a lightweight monitor? Just into the synthetics repo, or elsewhere?


@DougR it will technically go into beats repo GitHub - elastic/beats: 🐠 Beats - Lightweight shippers for Elasticsearch & Logstash