Synthetic Classic has reached end of support and is no longer available. Existing Synthetic Classic customers have been upgraded to the all-in-one Dynatrace software intelligence platform.

Backbone test settings

Settings for a Backbone test consist of:

When adding a test or when adding or editing a test template, only basic settings are available.

When editing a Backbone test, all settings are available.

When editing more than one test:

  • Only test-level alert settings are available.
  • The Basic Settings and Advanced Settings tabs are merged to create the Common Settings tab. This tab lists the tests you selected for editing and the Backbone settings that you can edit.

Basic Settings

Test List

If you selected more than one test to edit, the Test List section at the top of the page lists each test you selected to edit and its status.

To remove a test from editing, click . For more information about editing multiple tests, see Editing Peformance tests.

Edit Test Name

If you selected a single test to edit, the Edit Test Name field displays its name.

This setting is not available when creating a test template.

You can edit the test name. A name can only contain these characters:

  • Letters
  • Numbers
  • Spaces
  • Period ( . )
  • Forward slash ( / )
  • Colon ( : )
  • Underscore ( _ )
  • Equal sign ( = )
  • Comma ( , )

The name cannot include these reserved terms:

  • delete
  • drop
  • exec
  • insert
  • update

Specify Test URL

This setting appears for tests provisioned with URLs and for Web Recorder transactions. It shows the initial URL for the test. You can change the URL when editing the test, but be aware that the change may impact subsequent test actions.

The setting is not available when creating a template or for tests provisioned from a script.


If you provisioned a single-step test using a script that was edited in the Windows Recorder (for example, to add validations or custom code), do not change the URL when editing the test in the Portal. If you change the URL, the test will lose all the script changes that were made in the Windows Recorder.

Select Test status

The test status can be:

  • Active – Currently collecting data based on the test configuration settings and is available for charting, reporting, and trending.
  • Inactive – Currently not collecting data and is available for charting only.
  • Delete – Remove the test from the Portal and the database. The test is not available for charting, reporting or trending. This option is not available when initially configuring a test.

This setting is not available when creating a provisioning template.

Nodes and IPv6 preference

IPv6 preference

Select the IPv6 preference for the nodes; the preference selected determines the nodes that appear in the list. Select:

  • IPv4/IPv6 Mixed – Use IPv6 if it is available, otherwise use IPv4.
  • IPv6 only
  • IPv4 only

The default value depends on the following:

  • When creating a new template or configuring a new URL transaction, the default value is the account preference. If there is no account preference the default value is IPv4/IPv6 Mixed.

  • When configuring a new transaction, the default value is determined in the following order, depending on whether a preference is designated:

    1. Template value
    2. Script preference setting
    3. Account preference
    4. IPv4/IPv6 Mixed
  • If you are adding multiple scripts and these scripts were configured in the Recorder with different IP preferences, the lowest common value is shown.

    For example, if you add two scripts, one configured as IPv6 only and the other as IPv4/IPv6 Mixed, the default value shown is IPv4/IPv6 Mixed.

    The values from high to low are:

    • IPv6 only
    • IPv6 only
    • IPv4/IPv6 Mixed
  • If a test was created before the IP preference setting was added to test settings, the default value is IPv4/IPv6 Mixed.


The list on the left shows the Backbone nodes that are not currently assigned to this test. The Selected Nodes list shows the nodes that are assigned to collect data for the test.

Select the Backbone nodes where this test should run. The maximum number of nodes that can be selected depends on your account. If you have Software Private Agents, you can assign them to a test the same as Backbone nodes.

  • Choose the nodes and click to move the nodes to the Selected Nodes list or double-click a node to move it to the Selected Nodes list.
  • Use the search field to enter criteria to locate the nodes. Nodes matching the search criteria appear in the list as the criteria is entered or change. To view all nodes again, clear the search field.
  • Select multiple adjacent nodes by holding the Shift key and using the mouse to select the first and last node you wish to select.
  • Select multiple discrete nodes by holding the Ctrl key and selecting the nodes.
  • An asterisk ( * ) after the node name indicates that the node is inactive. A (C) indicates that the node is enabled for the Chrome Agent.

Include Objects

A page object is a single downloaded file, such as HTML, a GIF image, a Java application, or a Shockwave file.

The Include Objects setting determines whether object- and component-level data is stored.

All Page Objects

If All Page Objects is selected, data is collected on each object on the page and object- and component-level data is stored for 45 days.

Selecting this option enables you to drill down to times for individual objects.

If you edit a test that was originally configured to test all page objects, then the No Page Objects option is not available as these agents automatically collect page objects.

No Page Objects

If No Page Objects is selected:

  • For transaction tests, all steps except the last one download all objects, but no object-level data is stored. The last step downloads only the root object (first 2XX return code) object.
  • For single-URL tests, only the root object (first 2XX return code) is downloaded and stored.

You can chart the response time for the page, but the drilldown to the individual objects on the page is not available. If object errors occur, the errors will not be reported in the Portal, and alerts will not be triggered.

Use this option to chart the flow of the steps in the transaction, but not the individual objects. If you are simply testing the availability of a site, you may not need the object load detail.

If No Page Objects is selected, the Screen Capture on Error (SCoE) setting is not available.

Test Frequency

Enter how often the test will run, in minutes.

The frequency range and default value depend on your account.

Each node will run the test according to this schedule.


Select from these options.

Enable Flash Playback

If the test has steps that include Flash content, you may want to enable Flash playback.

  • If Flash playback is not selected, the playback may only call for the basic Flash objects to be downloaded.
  • If Flash playback is selected, additional objects are called by Flash, which provides a more comprehensive view of the load.

In a Flex environment, it is almost always true that more objects will be called if you enable this option. If a site auto-executes Flash, it usually causes a large increase in the payload.

If you enable Flash playback, the Portal shows the performance impact of the auto-execute and provides accurate statistics for the true payload, not just the initial objects.

Enable Silverlight Playback

If the test has steps that include Silverlight content, you may want to enable Silverlight playback.

If you do not select it, the playback may only call for the basic Silverlight objects to be downloaded.

If you select this option, additional objects are called by Silverlight to provide a more comprehensive view of the load.

Enable SPDY Support

Select whether to enable SPDY support. This option is not available for Internet Explorer Browser Agent tests.

SPDY is a networking protocol for transporting web content and is designed to reduce the latency of web pages.

Include client (non-network) time in results

Client (non-network) time, also called render time, refers to the time it takes the client browser to render the page, as distinct from the time spent downloading objects for the page.

When a page is being displayed in the browser, there is processing time by the browser after the objects are downloaded. This non-network time is not displayed in a waterfall chart by default; however, you can enable the reporting of client rendering time in the charts.

  • If the option to include client (non-network) time is disabled, the objects are displayed in the waterfall chart one right after another.
  • If client (non-network) time is enabled, gaps appear while the rendering takes place before the next page download begins.

When you select this option, the waterfall chart displays W3C metrics.

You should disable this option when you want to create a performance baseline for alerting or to observe trends over time. With this option disabled, the metric does not fluctuate with client-side processing changes, so it provides you with a perspective of purely network and server time.

Screen Capture on Error (SCoE)

Use the Screen Capture on Error (SCoE) setting to capture transaction information when an availability error occurs at the time the test executes. The information that can be captured includes page shots, route tracing, and http header information. For details, see Viewing Screen Captures.

You must select All Page Objects to enable SCoE.

Note that a fixed number of tests per account can be configured for SCoE.

Set Test Expiration Date

Select the expiration date for the test.

  • Expires on – Click the calendar icon to select an expiration date from the calendar.
  • Expires in – Specify the number of days the test will run, to a maximum of 60 days.

The Portal automatically inactivates any test that reaches its expiration date at 0:00:00 GMT on the specified date.

Before the test expires, an email is sent to notify the contact person for the account of the pending test expiration.

If you need to find out who the contact person is for your account, or to change the contact person, open a Support ticket. You will need to provide your account name and account ID, which are displayed on the Account settings page.

This setting is not available when creating a provisioning template.

Save Test To

Use this setting to assign a test to a folder.

Use folders to organize tests if you have multiple tests running in your account. For example, if you have multiple tests for a website's workflow, you can group all these tests into a folder, and use the folder to create a Status overview tile in a custom dashboard to monitor the tests as a unit.

The folder options are:

  • Keep the default of <No Folder>.
  • Click <No Folder> and select an existing folder from the list.
  • Create a new folder: Select New folder and enter the folder name in the field.

Valid characters for a folder name are:

  • Letters
  • Numbers
  • Spaces
  • Period ( . )
  • Forward slash ( / )
  • Colon ( : )
  • Underscore ( _ )
  • Equal sign ( = )
  • Comma ( , )

The name cannot include the following reserved terms:

  • delete
  • drop
  • exec
  • insert
  • update

You can also use the Folder management page to create folders and manage their contents.

Advanced Settings

The Advanced Settings are available after you provision a test, when you open the test for editing. These settings are not available when you're creating a provisioning template.


Transaction Steps

By default, each step name is the URL of the page that begins the step. You can rename steps so that they are more descriptive. For example, in a test for a shopping website, name a step "View Checkout" instead of the URL for the page.

Parameters: Defaults

Use parameters to change script values without having to edit the script. This is a useful setting for values that change periodically, such as a password.

If parameters are defined in the transaction (recorded in the Web Recorder or the Windows Recorder), this section lists the default values. If needed, enter a new value for each parameter.

If no parameters are defined for the test, the message "There is no default parameter value" appears.

Parameters: Substitutions by Node

You can only use these settings if parameters are defined in the transaction. If no parameters are defined for the test, the message "There is no parameter substitution by node" appears in this section.

You can use this section to specify different parameter values for the different nodes on which the test runs. This is a useful technique for values that need different values when run from different locations. For example, if your website security may cause the test to fail if the same login is used for multiple locations, you can define a different login for each node.

The nodes selected here must first be selected in the Nodes section of the Basic Settings tab.

To specify parameter substitutions:

  1. Select a node from the list and click Add Node.
  2. Enter the value(s) this node should use when running the test.
  3. For each node, repeat steps 1 and 2.

To remove a node from this section, select it in the Remove column and click Remove.

User Agent

The User Agent identifies a specific Web browser to a Web server. Tests can be dynamically controlled to enable the test agent to mimic a particular Web browser.

Network throttling

Network throttling is available for tests that use Mobile scripts and run on the Backbone network. For information about creating these tests, see Adding Performance tests.

Use these settings to define the network speed the test will simulate. For example, to monitor how your website performs on a mobile device under different connection conditions, you can create tests that simulate typical 3G or 4G speeds.

  • Download – The download speed in kilobytes per second
  • Upload – The upload speed in kilobytes per second
  • Latency – The latency in microseconds

For detailed and updated carrier speeds for all cities, we recommend the OpenSignal mobile app available for iOS and Android. See Network throttling in Mobile tests that run on the Backbone network for details.

SLA Management: Health Monitor

Use the Health Monitor settings to define Service Level Agreement thresholds so you can evaluate test performance relative to the SLA.

  • Number of Tests – The number of historic test results that will be averaged for all of the test's nodes

    For example, if you specify 5 tests, the health monitor averages the response time for the last five test executions on the test's nodes and uses this average as a baseline for the current test.

  • Break Time – The maximum acceptable response time defined by the SLA, in seconds

  • Over Threshold – The maximum acceptable percentage of tests exceeding the SLA maximum response time

  • Caution Time – A response time that does not exceed the SLA but is a warning that performance is degrading

  • At Risk – The maximum acceptable percentage of tests exceeding the Caution Time

In the Synthetic Classic Portal, the performance chart in the Performance dashboard displays Caution and Break lines for the SLA thresholds defined in the Health Monitor settings.

Maintenance Windows

Use this setting to define a test-level maintenance window. Administrators can also set account-level maintenance windows.

There are two types of maintenance windows:

  • Test – The test does not run during the specified time period. Alerting is also temporarily stopped. This is the default value.
  • Alert – The test runs as scheduled however, alerting is temporarily stopped.

Set a recurring or one-time maintenance window by clicking Add Window.

To delete a maintenance window, select X in the row of the window to delete.

Tests can also be added to or removed from maintenance windows in the Maintenance windows page. To go to this page, select Menu icon > Maintenance window.

Recurring Maintenance Windows

Use recurring maintenance windows to define time periods during which testing and alerting or only alerting will temporarily be stopped.

Select the type of window, day, start time, and end time for this window.

By default, this is populated by any maintenance windows listed in the Test defaults page.

One-time Maintenance Windows

Set a single, specific time, during which time testing and alerting or only alerting will be temporarily stopped.

The one-time maintenance window begins at an explicit start date and ends at an explicit end date. After this defined date range, the one-time maintenance window will have no further behavior.

Select the type of window, start date and time, and end date and time.