Synthetic Execution Types

[sivart_89]

We have a browser clickpath synthetic running every 5 minutes, scheduled through dynatrace not through something such as a cron job hitting the on demand execution endpoint every 5 minutes. When looking at the details of this synthetic I sometimes a execution type of 'standard' which I take it as being the standard scheduled run. I then sometimes see an execution type of 're-run' which I take as being a re-run of the synthetic because the previous run failed and because we have the 'Automatic retry on error' enabled within the outage handling. I have also seen an 'on-update' execution type. Is there any documentation on what these execution types represent?

I don't imagine the re-run and standard execution type is different than what I am thinking it is but I have no clue what the on-update type is.

[HannahM]

Great question. There are 4 execution types for Browser monitors:

1. Standard
   execution of a monitor with retry on error disabled or
   execution of a monitor with retry on error enabled that was successful on the 1st run
2. re-run
   2nd execution (retry) of a monitor that has retry on error enabled 
3. on-update
   1st execution made after an update to the monitor
4. on-demand
   execution run using the on-demand feature

[sivart_89]

Thank you! Clears things up now.

[Parkash_Jha_1]

Hi @HannahM ,

Could you please clarify where we can find the details of the initial run when the execution type is marked as a re-run due to failure?

Additionally, if the detailed breakdown in the screenshot shows no errors, how can this be classified as a failed execution? We have set a wait validation time of 20 seconds, but the entire execution is completing within 4.54 seconds. How can this be considered a valid timeout if it does not reach the 20-second threshold?

Regards,

Parkash

[HannahM]

Hi Parkash, 

in the case of re-runs, the initial failed execution is not visible in the WebUI. For private locations, you can check the execution log in the vup-logs or vup-archivedLogs folder. There's some information on searching for logs here, although you are not looking for the same player error. For public locations, you would need to ask on chat for assistance. 

In your screenshots, I can see that the monitor to 25s to run, you can see that from the start and end time. 

The time in the waterfall is resource timings. So if there were no resource timings provided from the browser api then nothing will be reported. The monitor failed because it had waited for 20s and the page had not loaded, as can be seen from the 'Actual' screenshot. If you would like the page to wait longer, I would recommend increasing the wait to 60s, as Wait for a specified element will move on as soon as the element appears anyway. 

[dg]

It looks like there is now also `on-creation`, which I don't recall having seen before. Was this added recently? Is there a way to prevent monitors from being executed automatically upon creation?

[HannahM]

Yes, on-creation is an execution type I missed. It's been around for a while now. There is no way to pervent monitors being executed automatically upon creation. 

[HannahM · Accepted solution]

Adding updated answer:

Great question. There are 5 execution types for Browser monitors:

1. Standard
   execution of a monitor with retry on error disabled or
   execution of a monitor with retry on error enabled that was successful on the 1st run
2. re-run
   2nd execution (retry) of a monitor that has retry on error enabled 
3. on-update
   1st execution made after an update to the monitor
4. on-demand
   execution run using the on-demand feature
5. on-creation
   1st execution made when a monitor is created. This is extra to the schedule and is run immediately after creation.