Waits and timeouts

Wait types

These wait types are supported in the Recorder:

  • Wait for Page Complete
  • Wait for Network
  • Wait for Event
  • Wait for Time
  • Wait for Validation

Wait for Page Complete

Wait for Page Complete is automatically created when the script is recorded, whenever a new page navigation takes place. It consists of a number of network waits as well as waits for specific document or browser events to occur.

The Wait for Page Complete settings include these waits:

  • Maximum Time to Wait
  • Page Complete Delay
  • Pending Read Wait

See below for definitions.

This wait is the only wait type that checks for DOM and browser states, to measure the full page load.

Best practice is to add a Wait for Network action after a Wait for Page Complete, to allow time for all activity related to loading the page to finish before moving on to the next action.

For example, if the page requires content that is loaded from an AJAX request and that AJAX doesn't respond quickly, the script will attempt to move on before the page is fully loaded, because the base HTML for the page is complete. The Wait for Network provides extra time for the AJAX request to be fulfilled.

Wait for Network

Wait for Network is designed to handle instances where network calls are made, but a new page doesn’t load. It is automatically generated by the Recorder while the script is recorded:

  • The agent waits between 200 ms and the Maximum Time to Wait default of 60 seconds for any pending network requests to complete.

  • If no requests are pending at 200 ms, the request is considered complete and the agent moves on to the next action.

  • The agent stops waiting as soon as the last pending request completes, or until it times out.

Wait for Network determines when an AJAX event is completed.

Do not use this wait type as a substitute for Wait for Page Complete, because:

  • Client processing will cause the Wait for Network to end prematurely.
  • This wait type does not include checks to verify that the appropriate DOM and browser events have occurred.

Wait for Event

Wait for Event provides a way to tell the agent to wait until a specific client-side event has happened, as opposed to waiting for a full page to load or for all network activity to subside. This wait type makes it possible to measure the “perceived” load time of a given page. You can select these possible event types for the wait:

  • DOMReady – The agent waits until the DOM is ready, although the page may still be loading additional content. Each agent determines DOMReady differently. The IE agent waits until the document's readyState is changed to interactive. The Firefox agent waits until the browser's DOMContentLoaded event is fired.
  • Load – The agent waits until the page's onload event has completed. The IE agent determines the load time by waiting until the target window's final DocumentComplete event is fired. The Firefox agent waits for the Firefox browser's load event to fire.

More information on browser-specific events is available in these external websites:

Wait for Time

Wait for Time blocks the agent from proceeding to the next action in the script for the specified number of seconds between starting the wait and executing the next action. It does not look at what events are happening or whether requests are still in progress when it completes.

Wait for Time is always a user-defined Wait action. The Recorder never records this wait type, and it does not have a default maximum value.

Insert a Wait for Time action in the script when the use case requires that the client wait the specified number of seconds before performing the next action. As a last resort, use this wait type as a workaround when other wait types time out but there are no script errors.

Wait for Validation

Wait for Validation pauses the script until the validation criteria that you specify are met.

This Wait action has a default timeout of 30 seconds.

You can specify the following validation criteria:

  • Text that appears on the target page when it is fully loaded. This is useful when the application may present a “loading…” page before the page the script needs to act on.
  • Element locators. The match should target a specific element on the page, not the entire HTML element. Matching against the entire HTML element may introduce errors, specifically on the Firefox agent.

Timeouts

All waits are bound by the configuration settings defined for the Browser Agents. In some cases, these values may require fine-tuning for the script to properly wait for the expected content. It is important to understand the different settings, know their default values, and recognize when it's appropriate to modify the defaults.

Timeout types

Wait timeout

All Wait actions, with the exception of Wait for Time, are capped by the wait timeout value. In the action configuration for the different wait types, this is the Maximum time to wait. If the agent is in a wait state that exceeds that value, it throws a wait timeout error, which is flagged as a Timeout Exceeded error in Dynatrace Synthetic data.

Default value – none

Maximum value – none

Page Complete Delay

The Page Complete Delay is applied within a Wait for Page Complete after the agent has confirmed that the browser's readyState is Complete. This wait provides a buffer in case there are any additional requests that need to go through.

Default value – none

Maximum value – none

Pending Read Wait

The Pending Read Wait is applied within a Wait for Page Complete to allow time for additional asynchronous events after the page is loaded.

Default value – 3 seconds

Maximum value – 3 seconds

Connection Timeout

The Connection Timeout is a network-level timeout reported by the agent when it fails to connect to a host server within the specified amount of time. The default value corresponds with the amount of time a real browser would take to report a connection timeout error.

Default value – 25 seconds

Maximum value – 25 seconds

Read Timeout

The Read Timeout is the value associated with the Socket Receive Timeout error reported in the Dynatrace Portal. This error occurs when the agent fails to receive any data from the host server within a specified window of time. The length of that window is defined by the Read Timeout value.

Default value – 40 seconds

Maximum value – 120 seconds

Soft Deadline

The Soft Deadline applies to the cumulative network time recorded for a given page, or for the entire transaction level. Network time includes all the response times that Dynatrace Synthetic reports, with the exception of Client Time.

Soft timeouts are reported as Timeout Exceeded Errors in the Dynatrace Portal.

Default value – 60 seconds

Maximum value:

  • Script and step – 240 seconds

  • Action – 220 seconds

Hard Deadline

The Hard Deadline applies to the same things as the Soft Deadline. The only difference is that if the Hard Deadline threshold is met, the data is automatically cut from the database. Usually this deadline is reached when the agent is stalled on a particularly large object on the page.

Default value – 90 seconds

Maximum value:

  • Script and step – 290 seconds

  • Action – 220 seconds

Scripting best practices and timeouts

Any step that exceeds the step Hard Deadline timeout of 90 seconds will be reclassified in the database, removing it from charts and preventing it from triggering alerts. If you manually adjust a step to add more waits, or combine multiple steps into one, ensure that they cannot logically exceed 90 seconds total, otherwise your script will trigger an auto-cut at exactly the time you want it to be throwing an alert.

Example: Step Hard Deadline timeout

In this example, the three wait statements after the FormFill and Click are:

  1. Wait for Page Complete
  2. Timed wait for 10 seconds
  3. Wait for Validation, with a default timeout of 60 seconds.

When Step 2 Login failed with a network error, Wait for Page Complete took about 30 seconds to complete. Adding the wait times together in the worst-case scenario suggests that the step could take 102 seconds. Since this is greater than the step Hard Deadline timeout limit of 90 seconds, the step would be auto-cut and the alert would not be triggered.

To avoid auto-cut, the Wait for Page Complete and Wait for Validation maximum timeout values should each be set to 30 seconds, so the maximum wait would be 2 + 30 + 10 + 30 = 72 seconds. A soft deadline timeout would be displayed in the Dynatrace Portal results, and would trigger an alert.

Troubleshooting timeout errors

  • If a script is throwing a timeout error, check the waterfall for that specific failure to see if a particular object is taking a long time to load.
  • To double-check the response times, manually perform the script steps in your local browser, making sure you are using the same browser as the script, and use a tool such as HTTP Watch to look at the response times. Note which nodes are throwing the error; it is possible the location of the node has a direct effect on the response times of the objects.
  • If a script is failing with a Wait for Page Complete error and the waterfall for that test run does not accurately represent the amount of network time needed to throw the error, it is likely that the page caused Wait for Page Complete to hang. To resolve this issue, replace the Wait for Page Complete with Wait for Event (specifically, a load event) followed by a Wait for Network action. This change allows the script to wait until the onload function is fired. The Wait for Network captures the remaining HTTP requests needed for the page to load.

The Connection Timeout is a network-level timeout reported by the agent when it fails to connect to a host server within the specified amount of time. The default value corresponds with the amount of time a real browser would take to report a connection timeout error.