How to increase wait times of Browser Clickpath events beyond 60 seconds

[Bill_Emerson]

• Summary
• Problem
• Troubleshooting steps
• Verify the expected page load time
• Change the wait strategy
• Block long-running third-party resources
• Resolution
• Option 1 - Increase the monitor and event timeouts for Private Locations​
• Option 2 - Add a Click event​
• Option 3 - Add aJavaScript event ​
• Best Practices​
• What's next

 

Summary

Synthetic Browser Clickpath events can time out if a site is very slow. Sometimes, extending the time allowed for a Synthetic action to complete can improve a Monitor's availability. This article will help you add time to these long-running actions.

Problem

Browser clickpaths have a 60-second timeout per event and a 5-minute timeout for the monitor; after that, you may see a hard timeout. How can this be handled when a site's performance is so slow that 60 seconds isn't enough time to complete an action? The timeout exists to prevent a monitor from using too much time on a testing location, but there may be scenarios when we must exceed the timeout.

Troubleshooting steps

Verify the expected page load time

If this browser clickpath is running on a

• Public Location
  • Try accessing the site from a computer that is outside of your network.
    
• Private Location
  • Try accessing the site from an ActiveGate that is part of the private location.
  • Another reason for long durations is a problem with the network location of the ActiveGate. If this is the case, also try accessing the site from other locations on your network to confirm the timing. 

Change the wait strategy

The browser clickpath may be waiting for something to finish downloading or change on the page that does not affect users or the scenario you're testing. If so, try using different wait criteria to see if you can find one that works for your situation.

• If nothing is changing on the page, for instance, after filling in a field on a form, then try changing the wait to 'None'
• If a specific element is needed before moving on to the next event,
  • initially try 'Wait for next event', which waits for the locators of the next event to be available.
  • If that doesn't help, try 'Wait for a specific element to appear'
• As a last resort, use the "Wait for a specific period of time" and set it for 60 seconds.

You can find more information on waits here.

Block long-running third-party resources

When checking the waterfall for a long-running execution, some resources are shown as 'pending'. This means they did not download before the 60s allowed. If these resources are third-party and not affecting the user experience, they can be blocked in the browser clickpath's Advanced Setup. See Block specific requests. 

If the page still can't load within the allowed time, you may need to add extra events to your script to make the browser's clickpath wait longer.

Resolution

Option 1 - Increase the monitor and event timeouts for Private Locations​

If the browser clickpath is only running on Private Synthetic Locations, the monitor and event timeouts can be updated using the Synthetic configuration API to increase the values of bmMonitorTimeout and bmStepTimeout.

The maximum settings are: 

"bmMonitorTimeout": 900000 (15 minutes)
"bmStepTimeout": 180000  (3 minutes)

If the browser clickpath will be running on Public Synthetic Locations, this solution won't help, as it only affects browser clickpath executions running on Private Synthetic Locations.

Option 2 - Add a Click event​

Since the default timeout is 60 seconds per event, you can add an event after the event that is experiencing timeouts to allow up to 60 seconds of further wait time.

1. In the browser clickpath's settings, open the Recorded Clickpath.
2. Select Add synthetic event.
3. Set the synthetic event type to be Click.
4. Set the new event to be added after the failing one.
5. Set the wait time of the new event to 'Wait for Next event' or another suitable wait.
6. Add a locator for the event.
   Select Type CSS and add body to the Input field.
   
7. Set the wait time of the original, failing event to be for a specific amount of time, up to 60 seconds

This technique allows additional wait time. If more than 60 seconds is needed, another event can be added. By using a click on the body element, there is some validation that a page is loading. If there is no body element to click on, this step will fail, indicating that the page isn't even starting to load after the initial step.

Option 3 - Add a JavaScript event ​

This technique is even more straightforward, but it doesn't interact with the page at all, so it doesn't have the validation from option 2. This option is helpful if the site is so slow that even the HTML isn't loaded before the initial step has finished waiting.

1. In the browser clickpath's settings, open the Recorded Clickpath.
2. select Add synthetic event.
3. Select the synthetic event type to be JavaScript.
4. Set the new event to be added after the failing one.
5. Leave the black code window blank.
6. Set the wait time of the new event to 'Wait for Next event' or another suitable wait.
   
7. Set the wait time of the original, failing event to be for a specific amount of time, up to 60 seconds.

Again, more events can be added for exceptionally poorly performing sites.

Best Practices​

• If a new event is added to a browser clickpath to increase the wait time, rename the new event to indicate it's just there to make the monitor wait longer. For example, something like "Click and Wait" or "Extend Wait Time." This makes its purpose clear to anyone else looking at the browser clickpath in the future.
• Try to limit the wait times to the minimum value that will allow the monitor to work. If waiting 30 seconds is enough to get 100% availability, then set the extra wait to 30 seconds. This will help the monitor continue to benchmark performance. We want the monitor to fail if the site takes longer than usual to load.
• Remember that the default total timeout of a browser clickpath is 5 minutes, which includes time used by these wait events. If a site is so slow that you need multiple wait events, you're only going to have time for a few actual functional events. This is another reason to limit the times of wait events to the minimum needed to pass.
• Having wait events may break up waterfall data over multiple events as the downloaded elements are spread across the original event and the wait event. So, the reporting of each event's timing could be fragmented.
• Adding wait events won't add time to Visually Complete or other metrics, as we only count network times for elements. However, as noted above, those metrics may be reported in different events depending on when the elements complete their download.
• Adding wait events may increase the cost of a monitor. Remember, Dynatrace Synthetic Monitors charge for actions and events that have network activity. If a page load is split across a navigate event and a wait event, you'll be charged for both.

What's next

If none of these steps provide enough time to load a page fully, this site may be too large or slow to be effectively monitored by a browser clickpath. You may have to rely on RUM to get performance data. However, if you believe the Monitor is not accurately reflecting the site's actual performance, please open a ticket with Dynatrace Support.

Please include:

• A link to the browser clickpath.
• The index number of the event that is failing.
• The name of the location where the browser clickpath is running.

You can find further troubleshooting tips for Synthetic in the Synthetic Troubleshooting Map