Synthetic Monitoring Troubleshooting
If you experience issues setting up or configuring Datadog Synthetic Monitoring, use this page to start troubleshooting. If you continue to have trouble, contact Datadog Support.
Network timings are varied
If you see a sudden spike or overall increase in your API test timing metrics, this usually indicates a bottleneck or delay in the request. For more information, see this guide on API Test Timings and Variations.
The website is not loading in the iframe
After downloading the Datadog extension, you are unable to see your website in the iframe on the right side of your Browser test’s recorder and the iframe displays
Your website does not support being loaded through an iframe.. This could mean that your application has some settings preventing it from being opened in an iframe. If that is the case, try opening your website in a popup by clicking Open in Popup to record your journey.
Some applications load in the iframe but some do not
This means your applications and environments have different restrictions, which causes some of them to be visualized in an iframe while the others are not viewable.
This most likely means you are trying to record steps on an
http page. Only
https is supported in the recorder iframe. You should open your page as a popup or change your URL to an
https one to start recording on the page.
My website is not loading in the iframe and I cannot record any steps, even when opening my website in a popup
After downloading the Datadog extension, you are unable to see your website in the iframe on the right side of your Browser test’s recorder. Additionally, you cannot record any steps, regardless of whether you open your website in the iframe or in a popup:
If that happens, ensure the Datadog extension has the permissions to read and change data on the intended websites by specifying your website in the
On specific sites section or by toggling
On all sites:
I’m unable to record steps on my application
Your Chrome browser might have some policies preventing the extension from performing the recording as expected.
To find out, go to
chrome://policy and look for any extension-related settings such as
I don’t see the login page in the recorder
By default, the iframe/popup of the recorder uses your own browser. This means that if you’re already logged into your application, the iframe/popup might directly display a post login page, therefore preventing you from recording your login steps without logging out first.
To be able to record your steps without logging out from your application, just leverage the recorder’s incognito mode:
Opening a popup window in incognito mode allows you to start your test’s recording from the start URL set in your test configuration with a session completely isolated from your own browser’s main session and user data.
This incognito popup window ignores your previous browser history including cookies and local data. You are automatically logged out from your account and can start recording your login steps as if you were visiting your website for the first time.
My mobile small or tablet browser test results keep failing
If your website is using responsive techniques, its DOM might differ a lot depending on the device your test is running on. It might use a specific DOM when running from a
Laptop Large, and have a different architecture when running from a
Tablet or a
This means that the steps you recorded from a
Laptop Large viewport might not be applicable to the same website accessed from a
Mobile Small, causing your
Mobile Small test results to fail:
For these types of cases, Datadog recommends creating separate
Mobile Small or
Tablet specific tests where the recorded steps match the viewport your test is set to at runtime.
To record steps with a
Mobile Small or
Tablet viewport, selecting
Mobile Small or
Tablet in the recorder dropdown before hitting the Start Recording button.
Additionally, Datadog’s test browsers run in headless, meaning Browser tests do not support some features. For example, Browser tests do not support
touch and cannot use
touch to detect whether the website should appear with its mobile design.
None or multiple elements detected step warning appears in browser tests
One of your browser test steps is showing a
None or multiple elements detected step warning:
This means that the user locator defined for that step is either targeting several elements, or none of them, consequently preventing the Browser test from knowing which element needs to be interacted with.
To fix it, go edit your recording, open the advanced options of the step that is having the issue, go to the page the step is testing, and click on
Test. This highlights the located element or prints an error message. You can then go ahead and fix your user locator to have it match a single element of the page:
I am having issues with a CSS pointer property
Automated browsers do not support emulating the CSS
pointer media feature. Browser tests have
pointer: none for all tests and devices (laptop, tablet, or mobile).
API and browser tests
If one of your Synthetic tests is throwing a 401, it most likely means that it is unable to authenticate on the endpoint. You should use the method that you use to authenticate on that endpoint (outside of Datadog) and replicate it when configuring your Synthetic test.
Is your endpoint using header-based authentication?
- Basic Authentication: specify the associated credentials in the Advanced options of your HTTP or Browser test.
- Token based authentication: extract your token with a first HTTP test, create a global variable by parsing the response of that first test, and re-inject that variable in a second HTTP or Browser test requiring the authentication token.
- Session based authentication: add the required headers or cookies in the Advanced options of your HTTP or Browser test.
Is this endpoint using query parameters for authentication (for example, do you need to add a specific API key in your URL parameters?)
Is this endpoint using IP-based authentication? If so, you might need to allow part or all of the IPs from which Synthetic tests originate.
If you observe
403 Forbidden errors returned by Synthetic tests, it may be the result of your web server blocking or filtering requests that include the
Sec-Datadog header. This header is added to each Synthetic request Datadog initiates to identify the source of the traffic and assist Datadog support in identifying the specific test execution.
Additionally, you might also have to ensure Datadog Synthetic Monitoring IP ranges are allowed as traffic sources by your firewalls.
Synthetic tests by default do not renotify. This means that if you add your notification handle such as your email address or Slack handle after a transition is generated (for example: a test going into alert or recovering from a previous alert), a notification is not sent for that transition. A notification is sent for the next transition.
My private location containers sometimes get killed
Private location containers getting killed
Out Of Memory generally uncover a resource exhaustion issue on your private location workers. Make sure your private location containers are provisioned with sufficient memory resources.
My browser test results sometimes show
Page crashed errors
This could uncover a resource exhaustion issue on your private location workers. Make sure your private location containers are provisioned with sufficient memory resources.
My tests are sometimes slower to execute
This could uncover a resource exhaustion issue on your private locations workers. Make sure your private location containers are provisioned with sufficient CPU resources.
My browser tests are taking too long to run
Confirm you are not seeing out of memory issues with your private location deployments. If you have tried scaling your container instances following the dimensioning guidelines already, reach out to Datadog Support.
TIMEOUT errors appear in API tests executed from my private location
This might mean your private location is unable to reach the endpoint your API test is set to run on. Confirm that the private location is installed in the same network as the endpoint you are willing to test. You can also try to run your test on different endpoints to see if you get the same
TIMEOUT error or not.
invalid mount config for type "bind": source path must be a directory error appears when attempting to run a private location
This occurs when you attempt to mount a single file in a Windows-based container, which is not supported. For more information, see the Docker mount volume documentation. Ensure that the source of the bind mount is a local directory.
Additional helpful documentation, links, and articles: