Yes – this exact issue happens in high-latency environments, for example when testing from the US against systems in regions with weaker connectivity (Middle East, Africa, APAC). Dynatrace has hard limits – 60 seconds per event and 5 minutes per browser clickpath – but there are two ways to work around it:
If you are using a Private Location – you can increase the limits via the Synthetic Configuration API:
bmStepTimeout up to 180,000 ms (3 minutes)
bmMonitorTimeout up to 900,000 ms (15 minutes)
This is the only method that truly extends the hard per-step limit.
If the tests must run on a Public Location – you can work around the limit by adding extra events after the one that times out:
add a Click event on an element like body (set wait to “Wait for next event”),
or add a JavaScript event with empty code (just waits for the set duration).
Each such event adds another 60 seconds of wait time, and you can chain them together (but you’re still limited by the global 5-minute timeout).
Best practice:
First measure the actual page load time (ActiveGate + waterfall).
Extend the wait time only to the minimum required value so the monitor doesn’t give false failures — if 75 seconds is enough, don’t set 3 minutes.
Keep in mind that longer waits and additional events increase the cost of synthetic actions and may split metrics (like Visually Complete) across multiple steps.
If even with maximum values the page still doesn’t load within 5 minutes, Dynatrace recommends relying on RUM to get performance data instead of synthetics.
Would you like me to prepare an example Synthetic API payload with bmStepTimeout and bmMonitorTimeout already increased, so you can drop it into Postman or your automation script?
