If you experience issues setting up or configuring Datadog Synthetic Monitoring, use this information to begin troubleshooting. If you continue to have trouble, contact Datadog’s support team.
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. See this guide on API Test Timings and Variations to learn more.
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 pop up by clicking Open in Popup to record your journey.
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 pop up or change your URL to an https one to start recording on the page.
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 pop up:
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:
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 ExtensionSettings.
By default, the iframe/pop up of the recorder uses your own browser. This means that if you’re already logged into your application, the iframe/pop up 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 pop up 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.
The freshly opened incognito pop up ignores all your previous browser history: cookies, local data, etc. You are consequently automatically logged out from your account and can start recording your login steps as if you were visiting your website for the first time.
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 very different architecture when running from a Tablet or a Mobile Small.
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 warningOne 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:
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?
Is this endpoint using query parameters for authentication (e.g. 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 (email address, Slack handle, etc.) after a transition got generated (e.g., test going into alert or recovering from a previous alert), no notification is sent for that very transition. A notification will be sent for the next transition.
OOM.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.
Page crashed errorsThis could uncover a resource exhaustion issue on your private location workers. Make sure your private location containers are provisioned with sufficient memory resources.
This could uncover a resource exhaustion issue on your private locations workers. Make sure your private location containers are provisioned with sufficient CPU resources.
TIMEOUT errors on API tests executed from my private locationThis 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.
Check whether you are using API endpoints to trigger your CI/CD test runs. To have your CI Results Explorer populate with CI metadata, you must use the NPM package.
Additional helpful documentation, links, and articles:
