{"id":1023,"date":"2026-06-09T01:48:57","date_gmt":"2026-06-09T01:48:57","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1023"},"modified":"2026-06-09T01:48:58","modified_gmt":"2026-06-09T01:48:58","slug":"datadog-synthetic-tests-vs-synthetic-test-suites-complete-tutorial-guide","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/datadog-synthetic-tests-vs-synthetic-test-suites-complete-tutorial-guide\/","title":{"rendered":"Datadog Synthetic Tests vs Synthetic Test Suites: Complete Tutorial Guide"},"content":{"rendered":"\n

1. Simple Meaning<\/h2>\n\n\n\n

In Datadog, Synthetic Tests<\/strong> are the actual checks that run against your application.<\/p>\n\n\n\n

A Synthetic Test Suite<\/strong> is a logical group of multiple Synthetic Tests.<\/p>\n\n\n\n

Think of it like this:<\/p>\n\n\n\n

Concept<\/th>Simple Meaning<\/th><\/tr><\/thead>
Synthetic Test<\/td>One actual test\/check<\/td><\/tr>
Synthetic Test Suite<\/td>A folder\/group containing many tests<\/td><\/tr>
SLO<\/td>Reliability target based on uptime\/availability<\/td><\/tr>
Dashboard SLO Widget<\/td>Visual display of an existing SLO<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Example:<\/p>\n\n\n\n

You may have these individual Synthetic Tests:<\/p>\n\n\n\n

Synthetic Test<\/th>Purpose<\/th><\/tr><\/thead>
Login API uptime test<\/td>Checks login endpoint<\/td><\/tr>
Homepage browser test<\/td>Checks website loads<\/td><\/tr>
Checkout browser test<\/td>Checks checkout flow<\/td><\/tr>
Payment API test<\/td>Checks payment endpoint<\/td><\/tr>
gRPC health check<\/td>Checks gRPC service health<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Then you can create a Test Suite called:<\/p>\n\n\n\n

Production Critical User Journey<\/code><\/p>\n\n\n\n

And add all those tests inside it.<\/p>\n\n\n\n

The suite does not replace the tests. It only groups them and gives you a combined operational view.<\/p>\n\n\n\n

\n\n\n\n

2. What is a Datadog Synthetic Test?<\/h1>\n\n\n\n

A Synthetic Test<\/strong> is an automated test run by Datadog to check whether your application, endpoint, website, API, or user journey is working.<\/p>\n\n\n\n

It can run from:<\/p>\n\n\n\n

Location Type<\/th>Meaning<\/th><\/tr><\/thead>
Datadog managed location<\/td>Public Datadog location around the world<\/td><\/tr>
Private location<\/td>Your internal network, VPC, Kubernetes, or private environment<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Synthetic Tests are useful because they test the system from the outside, like a real user or client.<\/p>\n\n\n\n

Example:<\/p>\n\n\n\n

Every 5 minutes:\nDatadog calls https:\/\/api.example.com\/health\nExpected status: 200\nExpected response time: less than 1 second\nIf it fails for 2 runs, alert the team.\n<\/code><\/pre>\n\n\n\n
That is a Synthetic Test.<\/p>\n\n\n\n
\n\n\n\n
3. Types of Synthetic Tests<\/h1>\n\n\n\n
Datadog supports multiple kinds of Synthetic Tests.<\/p>\n\n\n\n
3.1 API Tests<\/h2>\n\n\n\n
API tests check backend endpoints and network services.<\/p>\n\n\n\n
Common API test types:<\/p>\n\n\n\n
API Test Type<\/th>Purpose<\/th><\/tr><\/thead>
HTTP<\/td>Check REST\/API endpoint<\/td><\/tr>
SSL<\/td>Check certificate validity<\/td><\/tr>
DNS<\/td>Check DNS resolution<\/td><\/tr>
TCP<\/td>Check TCP port connectivity<\/td><\/tr>
UDP<\/td>Check UDP service<\/td><\/tr>
ICMP<\/td>Ping-style network check<\/td><\/tr>
WebSocket<\/td>Check WebSocket service<\/td><\/tr>
gRPC<\/td>Check gRPC endpoint<\/td><\/tr>
Multistep API<\/td>Chain multiple API calls together<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Example use cases:<\/p>\n\n\n\n
Use Case<\/th>Test Type<\/th><\/tr><\/thead>
Check \/health<\/code> endpoint<\/td>HTTP API test<\/td><\/tr>
Check certificate expiry<\/td>SSL test<\/td><\/tr>
Check DNS record<\/td>DNS test<\/td><\/tr>
Check gRPC health endpoint<\/td>gRPC test<\/td><\/tr>
Login \u2192 get token \u2192 call protected API<\/td>Multistep API test<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
3.2 Browser Tests<\/h2>\n\n\n\n
Browser tests simulate real user actions in a browser.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
Open homepage\nClick Login\nEnter username and password\nClick Submit\nVerify dashboard is visible\n<\/code><\/pre>\n\n\n\n
Browser tests are useful for validating frontend flows.<\/p>\n\n\n\n
Common use cases:<\/p>\n\n\n\n
Use Case<\/th>Browser Test?<\/th><\/tr><\/thead>
Login flow<\/td>Yes<\/td><\/tr>
Checkout flow<\/td>Yes<\/td><\/tr>
Search flow<\/td>Yes<\/td><\/tr>
Form submission<\/td>Yes<\/td><\/tr>
Page rendering validation<\/td>Yes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
3.3 Mobile Application Tests<\/h2>\n\n\n\n
Mobile app tests validate mobile application flows on real devices.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
Open mobile app\nTap login\nEnter credentials\nVerify home screen appears\n<\/code><\/pre>\n\n\n\n
Use this when your customer journey is inside an Android or iOS app.<\/p>\n\n\n\n
\n\n\n\n
4. What is a Synthetic Test Suite?<\/h1>\n\n\n\n
A Synthetic Test Suite<\/strong> is a collection of existing Synthetic Tests.<\/p>\n\n\n\n
It helps you organize tests by:<\/p>\n\n\n\n
Grouping Style<\/th>Example<\/th><\/tr><\/thead>
User journey<\/td>Login suite, checkout suite, booking suite<\/td><\/tr>
Environment<\/td>Production suite, staging suite<\/td><\/tr>
Service<\/td>Payment service suite, auth service suite<\/td><\/tr>
Team<\/td>Platform team suite, frontend team suite<\/td><\/tr>
Criticality<\/td>Tier-1 critical tests, non-critical tests<\/td><\/tr>
Location<\/td>Japan user journey, US user journey<\/td><\/tr>
Application<\/td>Web app suite, mobile app suite<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Example:<\/p>\n\n\n\n
Suite Name: Production Checkout Journey\n\nTests inside:\n1. Homepage browser test\n2. Login browser test\n3. Product search browser test\n4. Add to cart browser test\n5. Payment API test\n6. Order confirmation API test\n<\/code><\/pre>\n\n\n\n
The Test Suite helps you see whether the overall checkout journey is healthy.<\/p>\n\n\n\n
\n\n\n\n
5. Main Difference Between Synthetic Test and Synthetic Test Suite<\/h1>\n\n\n\n
Area<\/th>Synthetic Test<\/th>Synthetic Test Suite<\/th><\/tr><\/thead>
Main purpose<\/td>Runs an actual check<\/td>Groups multiple tests<\/td><\/tr>
Does it execute a request\/browser\/mobile flow?<\/td>Yes<\/td>No, it triggers or organizes existing tests<\/td><\/tr>
Unit of monitoring<\/td>One endpoint, one browser flow, one mobile flow, one API sequence<\/td>A collection of tests<\/td><\/tr>
Alerting<\/td>Alert on individual test failure<\/td>Alert on suite-level condition<\/td><\/tr>
Dashboard use<\/td>Can be shown directly or used for SLO creation<\/td>Used for grouped visibility and suite health<\/td><\/tr>
SLO creation<\/td>Usually manual Monitor-based SLO<\/td>Current docs do not clearly show automatic SLO creation<\/td><\/tr>
Ownership<\/td>Usually owned by service\/app team<\/td>Usually owned by team, product, journey, or environment<\/td><\/tr>
Best for<\/td>Precise technical monitoring<\/td>Business journey or operational grouping<\/td><\/tr>
Example<\/td>GET \/health should return 200<\/code><\/td>Production Checkout Critical Tests<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
6. Features Available in Synthetic Tests<\/h1>\n\n\n\n
These are mainly features of individual Synthetic Tests.<\/p>\n\n\n\n
Feature<\/th>Available in Synthetic Test?<\/th>Notes<\/th><\/tr><\/thead>
API endpoint check<\/td>Yes<\/td>HTTP, DNS, SSL, TCP, UDP, ICMP, WebSocket, gRPC<\/td><\/tr>
Browser journey recording<\/td>Yes<\/td>Simulates real user flow<\/td><\/tr>
Mobile app journey testing<\/td>Yes<\/td>Tests Android\/iOS app flows<\/td><\/tr>
Assertions<\/td>Yes<\/td>Validate status code, text, response time, UI element, etc.<\/td><\/tr>
Request headers\/body<\/td>Yes<\/td>Useful for API tests<\/td><\/tr>
Authentication handling<\/td>Yes<\/td>API tokens, cookies, login steps, variables<\/td><\/tr>
Multistep API chaining<\/td>Yes<\/td>Pass data from one request to another<\/td><\/tr>
Test frequency<\/td>Yes<\/td>Example: every 1 min, 5 min, 15 min<\/td><\/tr>
Managed locations<\/td>Yes<\/td>Run from Datadog locations<\/td><\/tr>
Private locations<\/td>Yes<\/td>Run from inside private network<\/td><\/tr>
Alert conditions<\/td>Yes<\/td>Configure when test should alert<\/td><\/tr>
Retry behavior<\/td>Yes<\/td>Reduce false positives<\/td><\/tr>
Per-test uptime<\/td>Yes<\/td>Available from test results<\/td><\/tr>
Monitor-based SLO source<\/td>Yes<\/td>Common SLO source for uptime<\/td><\/tr>
CI\/CD execution<\/td>Yes<\/td>Can run tests in pipeline<\/td><\/tr>
Terraform\/API management<\/td>Yes<\/td>Can manage tests as code<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
7. Features Available in Synthetic Test Suites<\/h1>\n\n\n\n
These are mainly features of Test Suites.<\/p>\n\n\n\n
Feature<\/th>Available in Test Suite?<\/th>Notes<\/th><\/tr><\/thead>
Group multiple tests<\/td>Yes<\/td>Main purpose of Test Suite<\/td><\/tr>
Add existing tests<\/td>Yes<\/td>You add already-created Synthetic Tests<\/td><\/tr>
Group by journey\/environment\/team<\/td>Yes<\/td>Very useful for organization<\/td><\/tr>
Suite-level view<\/td>Yes<\/td>See related tests in one place<\/td><\/tr>
Suite-level test runs tab<\/td>Yes<\/td>Useful for grouped execution history<\/td><\/tr>
Global uptime metrics<\/td>Yes<\/td>Suite view can show aggregated uptime-style metrics<\/td><\/tr>
Suite-level alerting<\/td>Yes, depending on site\/support<\/td>Suite alerts are separate from individual alerts<\/td><\/tr>
Mark tests critical\/ignored<\/td>Yes<\/td>Used for suite-level alert decisions<\/td><\/tr>
Alert when percentage of critical tests fail<\/td>Yes<\/td>Useful for reducing noise<\/td><\/tr>
Run multiple tests manually<\/td>Yes<\/td>Current docs mention max 50 tests can be run at a time<\/td><\/tr>
Maximum tests per suite<\/td>Yes<\/td>Current docs mention up to 300 tests per suite<\/td><\/tr>
Replace individual tests<\/td>No<\/td>Suite only groups tests; it does not become the real test<\/td><\/tr>
Per-endpoint assertion<\/td>No<\/td>Assertions live inside individual tests<\/td><\/tr>
Per-step browser recording<\/td>No<\/td>Browser steps live inside browser tests<\/td><\/tr>
Per-test request configuration<\/td>No<\/td>Request config lives inside the individual test<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
8. Feature Comparison: What One Has and the Other Does Not<\/h1>\n\n\n\n
8.1 Features Synthetic Tests Have, But Test Suites Do Not<\/h2>\n\n\n\n
Feature<\/th>Synthetic Test<\/th>Test Suite<\/th><\/tr><\/thead>
Actual HTTP\/API request execution<\/td>Yes<\/td>No<\/td><\/tr>
Actual browser recording steps<\/td>Yes<\/td>No<\/td><\/tr>
Actual mobile app test steps<\/td>Yes<\/td>No<\/td><\/tr>
Assertions<\/td>Yes<\/td>No<\/td><\/tr>
Request headers\/body<\/td>Yes<\/td>No<\/td><\/tr>
gRPC proto\/method behavior config<\/td>Yes<\/td>No<\/td><\/tr>
DNS\/SSL\/TCP\/UDP\/ICMP configuration<\/td>Yes<\/td>No<\/td><\/tr>
Authentication details<\/td>Yes<\/td>No<\/td><\/tr>
Response validation<\/td>Yes<\/td>No<\/td><\/tr>
Direct monitor for one endpoint\/flow<\/td>Yes<\/td>No<\/td><\/tr>
Direct source for Monitor-based SLO<\/td>Yes<\/td>Not usually the direct source<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
8.2 Features Test Suites Have, But Synthetic Tests Do Not<\/h2>\n\n\n\n
Feature<\/th>Synthetic Test<\/th>Test Suite<\/th><\/tr><\/thead>
Group many tests together<\/td>No<\/td>Yes<\/td><\/tr>
View journey-level health<\/td>Limited<\/td>Yes<\/td><\/tr>
Suite-level alerting<\/td>No<\/td>Yes<\/td><\/tr>
Mark tests as Critical or Ignored for suite alert<\/td>No<\/td>Yes<\/td><\/tr>
Alert based on percentage of critical tests failing<\/td>No<\/td>Yes<\/td><\/tr>
Run selected tests together<\/td>No<\/td>Yes<\/td><\/tr>
Manage tests by business journey<\/td>Limited<\/td>Yes<\/td><\/tr>
See all related tests in one place<\/td>No<\/td>Yes<\/td><\/tr>
Troubleshoot grouped failures<\/td>Limited<\/td>Yes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
9. SLO Behavior: Very Important<\/h1>\n\n\n\n
This is where confusion usually happens.<\/p>\n\n\n\n
A Synthetic Test<\/strong> and an SLO<\/strong> are not the same thing.<\/p>\n\n\n\n
A Synthetic Test checks whether something is working.<\/p>\n\n\n\n
An SLO defines a reliability target, such as:<\/p>\n\n\n\n
The login API should be available 99.9% of the time over 30 days.\n<\/code><\/pre>\n\n\n\n
9.1 For Individual Synthetic Test SLO<\/h2>\n\n\n\n
The usual flow is:<\/p>\n\n\n\n
Synthetic Test\n   \u2193\nDatadog Monitor\n   \u2193\nMonitor-based SLO\n   \u2193\nDashboard SLO Widget\n<\/code><\/pre>\n\n\n\n
Example:<\/p>\n\n\n\n
Item<\/th>Example<\/th><\/tr><\/thead>
Synthetic Test<\/td>prod-login-api-health<\/code><\/td><\/tr>
Monitor<\/td>Auto\/linked Synthetic monitor<\/td><\/tr>
SLO<\/td>Login API availability 99.9%<\/code><\/td><\/tr>
Dashboard widget<\/td>SLO widget showing error budget<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
9.2 For Test Suite SLO<\/h2>\n\n\n\n
Be careful here.<\/p>\n\n\n\n
A Test Suite gives you grouped visibility and suite-level alerting, but you should not assume that creating a Test Suite will always create a visible SLO automatically.<\/p>\n\n\n\n
If you want a Dashboard SLO widget, the safest approach is:<\/p>\n\n\n\n
Requirement<\/th>Recommended Action<\/th><\/tr><\/thead>
Show SLO for one endpoint<\/td>Create Monitor-based SLO from that Synthetic Test<\/td><\/tr>
Show SLO for one browser journey<\/td>Create Monitor-based SLO from that Browser Test<\/td><\/tr>
Show SLO for critical business journey<\/td>Create SLO from one or more important monitors, or use suite-level alerting separately<\/td><\/tr>
Show grouped health<\/td>Use Test Suite view and dashboard widgets<\/td><\/tr>
Avoid missing SLO confusion<\/td>Create SLOs manually and name\/tag them clearly<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
10. Alerting Difference<\/h1>\n\n\n\n
10.1 Synthetic Test Alerting<\/h2>\n\n\n\n
Synthetic Test alerting is precise.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
Alert if login API fails from 2 of 3 locations for 5 minutes.\n<\/code><\/pre>\n\n\n\n
Good for:<\/p>\n\n\n\n
Use Case<\/th>Why<\/th><\/tr><\/thead>
Endpoint down<\/td>Direct failure<\/td><\/tr>
SSL expiry<\/td>Direct certificate issue<\/td><\/tr>
DNS problem<\/td>Direct DNS validation<\/td><\/tr>
One browser flow broken<\/td>Direct user journey issue<\/td><\/tr>
gRPC method broken<\/td>Direct RPC validation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
10.2 Test Suite Alerting<\/h2>\n\n\n\n
Test Suite alerting is broader.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
Alert if 30% of critical tests in the checkout suite fail.\n<\/code><\/pre>\n\n\n\n
Good for:<\/p>\n\n\n\n
Use Case<\/th>Why<\/th><\/tr><\/thead>
Avoid alert storm<\/td>One suite alert instead of many test alerts<\/td><\/tr>
Business journey monitoring<\/td>Checkout\/login\/payment grouped together<\/td><\/tr>
Operations dashboard<\/td>Easier for NOC\/SRE\/team dashboard<\/td><\/tr>
Prioritization<\/td>Critical tests can trigger alert; ignored tests do not<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
11. Recommended Design Pattern<\/h1>\n\n\n\n
For a production application, use both.<\/p>\n\n\n\n
Layer 1: Individual Synthetic Tests<\/h2>\n\n\n\n
Create individual tests for each important endpoint or journey.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
Test Name<\/th>Type<\/th>Purpose<\/th><\/tr><\/thead>
prod-homepage-browser<\/code><\/td>Browser<\/td>Homepage availability<\/td><\/tr>
prod-login-api<\/code><\/td>HTTP API<\/td>Login endpoint<\/td><\/tr>
prod-checkout-browser<\/code><\/td>Browser<\/td>Checkout user journey<\/td><\/tr>
prod-payment-api<\/code><\/td>HTTP API<\/td>Payment endpoint<\/td><\/tr>
prod-grpc-health<\/code><\/td>gRPC<\/td>gRPC service health<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Layer 2: Test Suites<\/h2>\n\n\n\n
Group those tests into suites.<\/p>\n\n\n\n
Suite Name<\/th>Included Tests<\/th><\/tr><\/thead>
prod-critical-uptime-suite<\/code><\/td>Login, homepage, payment, checkout<\/td><\/tr>
prod-checkout-journey-suite<\/code><\/td>Search, cart, payment, order confirmation<\/td><\/tr>
staging-release-validation-suite<\/code><\/td>Smoke tests before release<\/td><\/tr>
auth-service-suite<\/code><\/td>Login, token, refresh, logout<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Layer 3: SLOs<\/h2>\n\n\n\n
Create SLOs for what leadership and SRE care about.<\/p>\n\n\n\n
SLO Name<\/th>Source<\/th><\/tr><\/thead>
Login API Availability 99.9%<\/code><\/td>Login API Synthetic monitor<\/td><\/tr>
Checkout Journey Availability 99.5%<\/code><\/td>Checkout browser monitor or selected monitors<\/td><\/tr>
Payment API Availability 99.9%<\/code><\/td>Payment API Synthetic monitor<\/td><\/tr>
Production Critical Uptime<\/code><\/td>Carefully selected critical monitors<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Layer 4: Dashboard<\/h2>\n\n\n\n
Create a dashboard with:<\/p>\n\n\n\n
Widget<\/th>Purpose<\/th><\/tr><\/thead>
SLO widget<\/td>Reliability target and error budget<\/td><\/tr>
Synthetic test summary<\/td>Current test health<\/td><\/tr>
Timeseries<\/td>Latency trend<\/td><\/tr>
Top list\/table<\/td>Failing locations\/tests<\/td><\/tr>
Test Suite status<\/td>Business journey health<\/td><\/tr>
Logs\/APM links<\/td>Troubleshooting<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
12. Naming Convention Best Practice<\/h1>\n\n\n\n
Use consistent names. This makes SLOs, dashboards, and suites much easier to manage.<\/p>\n\n\n\n
Recommended naming:<\/p>\n\n\n\n
<env>-<service-or-journey>-<test-type>-<purpose>\n<\/code><\/pre>\n\n\n\n
Examples:<\/p>\n\n\n\n
Name<\/th>Meaning<\/th><\/tr><\/thead>
prod-auth-api-login-health<\/code><\/td>Production login API health check<\/td><\/tr>
prod-web-browser-checkout-flow<\/code><\/td>Production checkout browser flow<\/td><\/tr>
stg-payment-api-smoke<\/code><\/td>Staging payment smoke test<\/td><\/tr>
prod-mobile-login-flow<\/code><\/td>Production mobile login test<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
For suites:<\/p>\n\n\n\n
<env>-<business-area>-suite\n<\/code><\/pre>\n\n\n\n
Examples:<\/p>\n\n\n\n
Suite Name<\/th>Meaning<\/th><\/tr><\/thead>
prod-critical-uptime-suite<\/code><\/td>Critical production checks<\/td><\/tr>
prod-checkout-journey-suite<\/code><\/td>Checkout journey tests<\/td><\/tr>
stg-release-validation-suite<\/code><\/td>Pre-release staging checks<\/td><\/tr>
prod-auth-service-suite<\/code><\/td>Auth service tests<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
For SLOs:<\/p>\n\n\n\n
<env> <service\/journey> Availability <target>\n<\/code><\/pre>\n\n\n\n
Examples:<\/p>\n\n\n\n
SLO Name<\/th>Meaning<\/th><\/tr><\/thead>
prod login API availability 99.9%<\/code><\/td>SLO for login API<\/td><\/tr>
prod checkout journey availability 99.5%<\/code><\/td>SLO for checkout flow<\/td><\/tr>
prod payment API availability 99.9%<\/code><\/td>SLO for payment endpoint<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
13. Tagging Best Practice<\/h1>\n\n\n\n
Tags are very important in Datadog.<\/p>\n\n\n\n
Recommended tags:<\/p>\n\n\n\n
Tag<\/th>Example<\/th><\/tr><\/thead>
env<\/code><\/td>env:prod<\/code><\/td><\/tr>
service<\/code><\/td>service:auth<\/code><\/td><\/tr>
team<\/code><\/td>team:platform<\/code><\/td><\/tr>
journey<\/code><\/td>journey:checkout<\/code><\/td><\/tr>
criticality<\/code><\/td>criticality:tier1<\/code><\/td><\/tr>
region<\/code><\/td>region:ap-northeast-1<\/code><\/td><\/tr>
owner<\/code><\/td>owner:sre<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Example:<\/p>\n\n\n\n
env:prod\nservice:payment\nteam:platform\njourney:checkout\ncriticality:tier1\n<\/code><\/pre>\n\n\n\n
This helps with filtering:<\/p>\n\n\n\n
Area<\/th>Benefit<\/th><\/tr><\/thead>
Synthetic test list<\/td>Quickly find tests<\/td><\/tr>
Test Suites<\/td>Add tests by tag<\/td><\/tr>
Dashboards<\/td>Filter by env\/team\/service<\/td><\/tr>
SLOs<\/td>Organize ownership<\/td><\/tr>
Cost attribution<\/td>Understand Synthetic usage<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
14. Practical Tutorial: How to Build This in Datadog<\/h1>\n\n\n\n
Step 1: Create Individual Synthetic Tests<\/h2>\n\n\n\n
Go to:<\/p>\n\n\n\n
Digital Experience \u2192 Synthetic Monitoring \u2192 New Test\n<\/code><\/pre>\n\n\n\n
Choose test type:<\/p>\n\n\n\n
Requirement<\/th>Choose<\/th><\/tr><\/thead>
Check REST API<\/td>API Test \u2192 HTTP<\/td><\/tr>
Check gRPC service<\/td>API Test \u2192 gRPC<\/td><\/tr>
Check website flow<\/td>Browser Test<\/td><\/tr>
Check mobile app flow<\/td>Mobile Application Test<\/td><\/tr>
Check SSL expiry<\/td>API Test \u2192 SSL<\/td><\/tr>
Check DNS<\/td>API Test \u2192 DNS<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Configure:<\/p>\n\n\n\n
Name\nURL\/endpoint\nLocations\nFrequency\nAssertions\nRetries\nAlerting condition\nTags\nNotification message\n<\/code><\/pre>\n\n\n\n
Save the test.<\/p>\n\n\n\n
\n\n\n\n
Step 2: Create a Test Suite<\/h2>\n\n\n\n
Go to:<\/p>\n\n\n\n
Digital Experience \u2192 Test Suites \u2192 New Test Suite\n<\/code><\/pre>\n\n\n\n
Configure:<\/p>\n\n\n\n
Suite name\nAdd existing Synthetic Tests\nMark tests as Critical or Ignored\nConfigure suite alerting if available\nSave Suite\n<\/code><\/pre>\n\n\n\n
Example:<\/p>\n\n\n\n
Suite Name: prod-checkout-journey-suite\n\nTests:\n- prod-homepage-browser\n- prod-login-api\n- prod-product-search-browser\n- prod-add-to-cart-browser\n- prod-payment-api\n- prod-order-confirmation-api\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
Step 3: Create SLOs Manually<\/h2>\n\n\n\n
Go to:<\/p>\n\n\n\n
Service Management \u2192 Service Level Objectives \u2192 New SLO\n<\/code><\/pre>\n\n\n\n
Choose:<\/p>\n\n\n\n
Monitor-based SLO\n<\/code><\/pre>\n\n\n\n
Then select the Synthetic monitor.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
SLO Name: prod login API availability 99.9%\nSource Monitor: prod-auth-api-login-health\nTarget: 99.9%\nWindow: 30 days\nTags:\n  env:prod\n  service:auth\n  team:platform\n<\/code><\/pre>\n\n\n\n
Save.<\/p>\n\n\n\n
\n\n\n\n
Step 4: Add SLOs to Dashboard<\/h2>\n\n\n\n
Go to:<\/p>\n\n\n\n
Dashboard \u2192 Edit \u2192 Add Widget \u2192 SLO Widget\n<\/code><\/pre>\n\n\n\n
Select the SLO you created.<\/p>\n\n\n\n
Important:<\/p>\n\n\n\n
A dashboard SLO widget does not create SLOs. It only displays SLOs that already exist.<\/p>\n\n\n\n
So if a new Synthetic Test is missing from the dashboard, check:<\/p>\n\n\n\n
Was an SLO created for it?\nWas the SLO added to the dashboard widget?\nAre dashboard filters hiding it?\nAre tags correct?\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
15. When to Use Synthetic Test vs Test Suite<\/h1>\n\n\n\n
Scenario<\/th>Use Synthetic Test<\/th>Use Test Suite<\/th><\/tr><\/thead>
Monitor one API endpoint<\/td>Yes<\/td>Optional<\/td><\/tr>
Monitor one SSL certificate<\/td>Yes<\/td>Optional<\/td><\/tr>
Monitor one gRPC service<\/td>Yes<\/td>Optional<\/td><\/tr>
Monitor login browser journey<\/td>Yes<\/td>Optional<\/td><\/tr>
Group all login-related checks<\/td>No<\/td>Yes<\/td><\/tr>
Group all checkout tests<\/td>No<\/td>Yes<\/td><\/tr>
Create business journey view<\/td>No<\/td>Yes<\/td><\/tr>
Create per-endpoint SLO<\/td>Yes<\/td>No<\/td><\/tr>
Reduce alert noise from many related tests<\/td>Maybe<\/td>Yes<\/td><\/tr>
Run smoke tests together<\/td>Maybe<\/td>Yes<\/td><\/tr>
Build executive dashboard<\/td>Yes, via SLOs<\/td>Yes, for grouped context<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
16. Common Confusions<\/h1>\n\n\n\n
Confusion 1: \u201cI created a Synthetic Test, but no SLO appeared.\u201d<\/h2>\n\n\n\n
That is expected.<\/p>\n\n\n\n
Create a Monitor-based SLO manually.<\/p>\n\n\n\n
Confusion 2: \u201cI created a Test Suite, but no new SLO appeared.\u201d<\/h2>\n\n\n\n
Do not assume Test Suite creation automatically creates a visible SLO in your SLO list.<\/p>\n\n\n\n
Check:<\/p>\n\n\n\n
Service Level Objectives page\nDashboard widget filters\nSuite page\nPermissions\nDatadog site support\n<\/code><\/pre>\n\n\n\n
If you need an SLO, create it manually.<\/p>\n\n\n\n
Confusion 3: \u201cI added tests to a suite, but they are missing old results.\u201d<\/h2>\n\n\n\n
Suite results normally apply from the time the test was added to the suite. For older history, check the individual test page.<\/p>\n\n\n\n
Confusion 4: \u201cShould I mute individual test alerts after adding suite alerting?\u201d<\/h2>\n\n\n\n
Maybe yes.<\/p>\n\n\n\n
If you enable suite-level alerting and individual test alerting, you may get duplicate notifications.<\/p>\n\n\n\n
Common approach:<\/p>\n\n\n\n
Test Type<\/th>Alerting Strategy<\/th><\/tr><\/thead>
Tier-1 critical individual test<\/td>Keep individual alert<\/td><\/tr>
Non-critical test in suite<\/td>Mute or reduce individual alert<\/td><\/tr>
Business journey suite<\/td>Enable suite alert<\/td><\/tr>
SLO-backed test<\/td>Keep alert carefully aligned with SLO<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
17. Recommended Alerting Strategy<\/h1>\n\n\n\n
Use this model:<\/p>\n\n\n\n
Level<\/th>Purpose<\/th>Example<\/th><\/tr><\/thead>
Individual Synthetic Alert<\/td>Precise technical failure<\/td>Login API down<\/td><\/tr>
Suite Alert<\/td>Business journey degraded<\/td>Checkout suite failing<\/td><\/tr>
SLO Burn\/Error Budget Alert<\/td>Reliability risk<\/td>Error budget burning too fast<\/td><\/tr>
Dashboard<\/td>Visibility and trend<\/td>SLO, uptime, latency, failures<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Best practice:<\/p>\n\n\n\n
Do not alert everyone for everything.\n<\/code><\/pre>\n\n\n\n
Recommended pattern:<\/p>\n\n\n\n
Test Criticality<\/th>Alert Behavior<\/th><\/tr><\/thead>
Tier-1 critical<\/td>Pager\/urgent alert<\/td><\/tr>
Tier-2 important<\/td>Team channel alert<\/td><\/tr>
Tier-3 informational<\/td>Dashboard only<\/td><\/tr>
Noisy\/non-critical<\/td>Suite-only or muted<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
18. Example Final Design<\/h1>\n\n\n\n
Synthetic Tests<\/h2>\n\n\n\n
Test<\/th>Type<\/th>Frequency<\/th>Alert<\/th><\/tr><\/thead>
prod-auth-api-login-health<\/code><\/td>HTTP API<\/td>5 min<\/td>Yes<\/td><\/tr>
prod-web-browser-login-flow<\/code><\/td>Browser<\/td>10 min<\/td>Yes<\/td><\/tr>
prod-payment-api-health<\/code><\/td>HTTP API<\/td>5 min<\/td>Yes<\/td><\/tr>
prod-checkout-browser-flow<\/code><\/td>Browser<\/td>15 min<\/td>Yes<\/td><\/tr>
prod-grpc-order-health<\/code><\/td>gRPC<\/td>5 min<\/td>Yes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Test Suites<\/h2>\n\n\n\n
Suite<\/th>Tests Included<\/th>Purpose<\/th><\/tr><\/thead>
prod-critical-uptime-suite<\/code><\/td>Auth, payment, checkout, order<\/td>Production critical health<\/td><\/tr>
prod-checkout-journey-suite<\/code><\/td>Homepage, search, cart, payment, confirmation<\/td>Business flow<\/td><\/tr>
stg-release-validation-suite<\/code><\/td>Smoke tests<\/td>Pre-release validation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
SLOs<\/h2>\n\n\n\n
SLO<\/th>Source<\/th>Target<\/th><\/tr><\/thead>
prod auth API availability<\/code><\/td>Auth API monitor<\/td>99.9%<\/td><\/tr>
prod payment API availability<\/code><\/td>Payment API monitor<\/td>99.9%<\/td><\/tr>
prod checkout journey availability<\/code><\/td>Checkout browser monitor<\/td>99.5%<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Dashboard<\/h2>\n\n\n\n
Dashboard Section<\/th>Widgets<\/th><\/tr><\/thead>
Executive summary<\/td>SLO widgets<\/td><\/tr>
Synthetic health<\/td>Test status widgets<\/td><\/tr>
Business journey<\/td>Test Suite status<\/td><\/tr>
Troubleshooting<\/td>Failed locations, latency, APM\/log links<\/td><\/tr>
Reliability<\/td>Error budget and burn rate<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
19. Final Recommendation<\/h1>\n\n\n\n
Use Synthetic Tests<\/strong> for actual monitoring.<\/p>\n\n\n\n
Use Test Suites<\/strong> for organization, grouped execution, suite-level visibility, and journey-level alerting.<\/p>\n\n\n\n
Use SLOs<\/strong> separately for reliability targets and dashboards.<\/p>\n\n\n\n
The clean design is:<\/p>\n\n\n\n
Synthetic Tests = actual checks\nTest Suites = grouped operational view\nSLOs = reliability target\nDashboard = visibility layer\nAlerts = action layer\n<\/code><\/pre>\n\n\n\n
For your case, where you created uptime tests and display them on a dashboard using SLO widgets:<\/p>\n\n\n\n
For each important Synthetic Test:\n1. Confirm the Synthetic Test exists.\n2. Confirm its monitor exists.\n3. Manually create a Monitor-based SLO.\n4. Add that SLO to the dashboard SLO widget.\n5. Optionally add the test into a Test Suite for grouped visibility.\n<\/code><\/pre>\n\n\n\n
Do not depend on Test Suite creation to automatically create every SLO you need.<\/p>\n\n\n\n
That manual SLO step is the safest and cleanest production approach.<\/p>\n","protected":false},"excerpt":{"rendered":"
1. Simple Meaning In Datadog, Synthetic Tests are the actual checks that run against your application. A Synthetic Test Suite is a logical group of multiple Synthetic… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[79],"tags":[],"class_list":["post-1023","post","type-post","status-publish","format-standard","hentry","category-datadog"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1023","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=1023"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1023\/revisions"}],"predecessor-version":[{"id":1024,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1023\/revisions\/1024"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1023"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1023"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1023"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}