API tests are useful to help you monitor your API endpoints and alert you when they are failing or too slow. These checks verify that your applications are responding to requests, as well as that they meet any conditions you define—such as response time, HTTP status code, and header or body contents. Use the Datadog API to see the full list.
SSL request you want to be executed by Datadog:
Define the request you want to be executed by Datadog:
Choose the Method and URL to query. Available methods are:
Name: The name of your API test.
Select your tags: The tags attached to your browser test. Use the
<KEY>:<VALUE> format to filter on a
<VALUE> for a given
<KEY> on the Synthetics page.
Locations: The Datadog managed locations to run the test from. Many AWS locations from around the world are available. The full list is retrievable through the Datadog API. You can also set up a Private Location to run a Synthetics API test on a private endpoint not accessible from the public internet.
How often should Datadog run the test? Intervals are available between every one minute to once per week.
Click on Test URL to try out the request configuration. You should see a response preview show up on the right side of your screen.
Hostand the SSL
Port. By default, the port is set to 443.
<KEY>:<VALUE>format to filter on a
<VALUE>for a given
<KEY>on the Synthetics page.
Set alert conditions to determine the circumstances under which you want a test to send an alert. When you set the alert conditions to:
An alert is triggered if any assertion fails for X minutes from any n of N locations, an alert is triggered if:
The uptime bar is displayed differently on your test result: location uptime is displayed on a per-evaluation basis (whether the last test was up or down). Total uptime is displayed based on the configured alert conditions. Notifications sent are based on the total uptime bar.
When running an API test, you must define at least one assertion that should be monitored by Datadog. An assertion is defined by a parameter, an optional property, a comparator, and a target value.
|Response time||Integer (ms)|
If you click on Test URL, then the basic assertions are automatically filled:
Response timelessThan 2000 ms
Header content-typeis “returned value”
Status codeis “returned value”
|certificate||Integer (number of days)|
If you click on Test URL, then the basic assertion is automatically filled:
certificateexpires in more than 10 days
You can create up to 10 assertions per API test by clicking on Add new assertion or by clicking directly on the response preview:
A test is considered
FAILED if it does not satisfy its assertions or if the request failed for another reason. These reasons include:
|The connection was abruptly closed by the remote server. Possible causes include the webserver encountering an error or crashing while responding, loss of connectivity of the webserver, etc.|
|DNS||DNS entry not found for the check URL. Possible causes include misconfigured check URL, wrong configuration of your DNS entries, etc.|
|The configuration of the check is invalid (e.g., typo in the URL).|
|The SSL connection couldn’t be performed. See the dedicated error page for more information.|
|The request couldn’t be completed in a reasonable time.|
If a test fails, the uptime directly considers the endpoint as
down. It is not re-tested until the next test run.
A notification is sent according to the set of alerting conditions. To configure notifications:
@-notificationfeature in the message field.
The Synthetics details page displays the following network timings:
|Time spent resolving the DNS name of the last request.|
|Time spent establishing a connection to the server.|
|Time spent for the TLS handshake. If the last request is not over HTTPS, this metric does not appear.|
|Time spent waiting for the first byte of response to be received.|
|Time spent downloading the response.|
Response time is the sum of these network timings.