Reducing Synthetic Browser Test Timeout

[MohammedRahman]

Hi Community,

I have set up a browser test with around 11 event and the test looks pretty stable. It runs from public locations.

I came to know that for each event it has a timeout of maximum of 60sec and overall timeout of maximum 5 minutes.

Actually this timeout threshold is high, is their a way to reduce this like for a overall timeout of 3 minutes ? because with such high timeout, we know that it will not fail.

and also is their a way to group 3 event and set some static threshold for eg: grouping navigate and entering username & pwd event as one and set a timeout of 30sec ?

the reason for this to check the applications availability more granularly because we know with the hard coded timeout the application would still work because it is already having more than enough time. 

[HannahM]

There is no way to change the default timeout for Browser Monitor events for executions run on Public locations. In general, the Monitor timeout is only hit on monitors that have a large number of steps, or for sites that are very slow, so each event takes a long time. For sites with a problem on a specific page, the step timeout is the more likely one for you to encounter, and that is only 60 seconds. 
If you are concerned about the monitor taking to long to load any specific pages then the performance thresholds would be a good option. This would alert you if a page took longer to load than expected. 
Performance thresholds can be set per event or for the monitor as a whole. If you are interested in alerting on the duration of a group of events, you would need to use a metric event for alerting. 

[tomaxp]

We cannot change the global timeout for Browser Monitors running from public locations, but there is a way to make them fail faster on specific steps.

As shown in the screenshot, you can configure a wait condition for each event:

• Wait for page to load completely – default behavior (up to 60s).

• Wait for a specific period of time – allows you to set a fixed, shorter wait (e.g. 5s).

• Wait for background network activity to complete – waits for XHR/fetch activity to finish.

• Wait for a specific element to appear – fails faster if the element does not show up within the defined limit.

• Wait for next event – immediately continues to the next step without waiting.

If you want to make your test more granular and fail earlier:

1. Set "Wait for specific element to appear" with a shorter timeout (e.g. 10–15 seconds) on critical steps.

2. Configure performance thresholds on those steps, so you get alerts if the event takes longer than expected (for example, more than 15 seconds).

3. Optionally, create a separate, shorter monitor for just the key navigation + login steps if you want even stricter SLAs.

This way, you keep the default monitor timeout but still ensure you get early failures and more precise availability checks for the critical steps.