Observability guide · Customer-facing services
Synthetic and real user monitoring: test your key customer journeys, and see what real users experience
Synthetic tests run scripted checks of your APIs and key journeys on a schedule, from locations you choose, including inside your own network. Real user monitoring (RUM) records what actual sessions experience in browsers and mobile apps. One tells you a journey has stopped working; the other tells you how it performs for the people using it. This guide covers which journeys to script first, where tests should run for a service in Saudi Arabia, how to handle logins protected by one-time passwords, and what RUM collects and how to mask it.
Published 8 min read
In short
- Synthetic tests answer "is this journey working right now?" They run whether or not anyone is using the service, so they can show a broken login at 3am.
- RUM answers "what are real users experiencing?" It needs real traffic, and it shows the devices, pages and errors that scripted tests do not cover.
- Private locations run Datadog's test worker inside your network, so internal systems can be tested, and public services can be tested from inside the Kingdom.
- Personal data: Session Replay masks page text and user input by default; decide before launch what else is masked or removed.
Two questions, two tools
| Synthetic tests | Real user monitoring (RUM) | |
|---|---|---|
| Question it answers | Does this journey or API work, from this location, right now? | How do pages and app screens perform for the people actually using them? |
| Where the data comes from | Scripted requests and browser steps run on a schedule | The Datadog SDK in your web pages or mobile apps, recording real sessions |
| Works without users | Yes, which makes it useful at night and before launch | No, it needs real traffic |
| Typical blind spot | Only the paths you scripted, from the locations you chose | Problems no user has hit yet, and journeys nobody is currently using |
| How Datadog counts usage | Per 10,000 API test runs and per 1,000 browser test runs | Per 1,000 sessions |
Most customer-facing services need both: synthetic tests for the few journeys that must never break, and RUM for everything else users do.
What Datadog Synthetic Monitoring can test
| Test type | Use it for |
|---|---|
| API tests (HTTP, SSL, DNS, WebSocket, TCP, UDP, ICMP, gRPC) | Checking that an endpoint answers correctly, that a certificate is valid, or that a host or port is reachable |
| Multistep API tests | Chained requests, such as: get a token, call the API with it, check the result |
| Browser tests | End-to-end journeys in Chrome, Firefox or Edge, at laptop, tablet or mobile screen sizes, recorded with Datadog's Chrome extension |
| Mobile application tests | Journeys in iOS and Android apps |
| Network path tests | The route packets take to an endpoint |
Tests can run from every minute to once a week. Results from tests run in CI/CD pipelines appear in the same results explorer, so the same journeys can be checked before a release and after it.
Which journeys to script first
Start with the journeys where a failure costs you customers or calls, not with every page. This is the order we suggest; adjust it to your service.
| Journey | Why it comes first | Test type | What the test should check |
|---|---|---|---|
| Login, including the one-time password step | Nothing else works if users cannot sign in | Browser test | The user reaches the signed-in page, not only the login form |
| Payment or checkout | Failures cost revenue directly | Browser test with a test account and test payment method | The confirmation step appears and the expected response comes back |
| Registration or onboarding | A failure here stops new customers before they start | Browser test | The account is created and the next screen loads |
| The main search or lookup | The most-used function after login | Browser or API test | Results return within the time you set |
| APIs that partners or mobile apps call | Partners may report failures late, or not at all | API or multistep API test | Status code, response time and key fields in the response |
| Certificates and DNS for public domains | An expired certificate breaks every journey on that domain at once | API test (SSL, DNS) | Days until expiry, and correct DNS answers |
Agree the list with the service owner and the operations team, and give each test an owner who will act on its alerts.
Where tests run: managed or private locations
Datadog runs tests from its own managed locations around the world, or from private locations that you host.
A private location is Datadog's test worker running inside your network. Datadog documents it as Docker containers, Kubernetes or Helm deployments, cloud container services, or a Windows service. It only sends outbound traffic, over port 443, to pull test configurations from Datadog and push results back, and it can go through a proxy. It supports API, multistep API and browser tests.
Read more
For a service in Saudi Arabia, a private location is useful in three cases:
- Internal systems. Applications and APIs that are not on the public internet can only be tested from inside the network.
- The view from the Kingdom. Datadog describes private locations as a way to create custom locations in areas that matter to your business. A worker in your own data centre or in a cloud region inside the Kingdom tests your service from close to your users. Check Datadog's current list of managed locations to see whether one is near your users as well.
- Before release. The same worker can test internal environments as part of CI/CD.
Test results are still sent to your Datadog site. As of November 2026 Datadog's sites are in the United States, Germany, Japan, Australia and the United Kingdom; see Observability data residency in Saudi Arabia.
Logins protected by one-time passwords
Datadog documents multi-factor authentication for browser tests using time-based one-time passwords (TOTP): the test generates the code from a secret stored as a global variable, the same way an authenticator app does. Its guide does not cover codes sent by SMS.
If your service sends the login code by SMS, agree a test approach with your security team before you script that journey:
Read more
- A dedicated test account that signs in with an authenticator-app code, so the browser test can generate it.
- A controlled test path for that one account only, documented and reviewed by security. Never relax one-time passwords for all users to make a test pass.
- Keep the secrets hidden: store credentials and secrets as global variables and switch on obfuscation, so their values do not appear in test results.
Alerting on journeys, not on single failures
A browser test can be set to alert only when its checks fail for a set number of minutes from a set number of locations, and to retry a failed location before counting it as failed. Use both:
- Require failure from more than one location before paging anyone, unless the journey only runs from one private location.
- Retry once before a location is marked as failed, so a single slow response does not wake the on-call engineer.
- Send journey alerts to the team that owns the journey, with a link to the test result and the related backend traces.
For how we decide which alerts deserve to exist at all, see How an alert earns its place.
RelatedHow an alert earns its place
What RUM collects, and how to keep personal data out
RUM records views (pages and screens), user actions, network requests, errors and crashes, and Core Web Vitals for web pages. Datadog provides SDKs for browsers, Android, iOS, React Native and Flutter, among others. Backend traces, logs and infrastructure metrics can be viewed alongside a RUM session, which shortens the path from "the page is slow" to the service that made it slow.
Read more
Session Replay adds a visual replay of browser sessions. Its privacy controls matter for any service that handles customer data:
- Default level is "mask": page text, user input, images, links and data attributes are masked, and masked data is not sent to Datadog in its original form.
- Other levels: "mask-user-input" masks form fields but records other text; "allow" records everything apart from the fields that are always masked. Individual elements can be set to mask, allow or hide.
- Always masked: password, e-mail and telephone input fields, and card-number, expiry and security-code fields, whatever level you choose.
- Before data is sent: the browser SDK lets you edit RUM events before they leave the page, or drop them (page views excepted), for example to remove e-mail addresses or national ID numbers from URLs.
Two decisions belong to you, not to the tool: which user identifier, if any, is attached to sessions, and where RUM data is stored. A pseudonymised ID keeps per-user analysis without sending names or numbers; see Keeping personal data out of logs and traces.
How Interkey helps
Interkey is an official Datadog partner and implements and operates Datadog for organisations in Saudi Arabia, including the set-up of Datadog Synthetic Monitoring and RUM. The work starts from the journey list on this page: agreeing with your service owners which journeys matter, scripting and testing them, placing private locations where your policy and your users require, setting alert conditions with the teams who will receive them, and agreeing Session Replay and RUM masking with your security team before any real session is recorded.
Questions buyers ask
Is synthetic monitoring the same as uptime monitoring?
Uptime checks are the simplest synthetic test: does the endpoint answer? Synthetic monitoring goes further, from multistep API calls to full browser journeys that sign in, search and pay.
Do we need both synthetic tests and RUM?
For customer-facing services, usually yes. Synthetic tests catch a broken journey even when nobody is using it; RUM shows how real users on real devices experience everything else. If you must start with one, start with synthetic tests on the journeys that cost most when they fail.
Can tests reach systems that are not on the internet?
Yes, from a private location inside your network. The worker only makes outbound connections to Datadog, so no inbound access to your network is needed.
Can you test login journeys that use SMS one-time passwords?
Datadog's documented method generates time-based codes, as an authenticator app does. For SMS-based logins, agree a dedicated test account and a reviewed test path with your security team; see the section on one-time passwords above.
Does Session Replay record what users type?
Not by default. The default level masks user input and page text, and password, e-mail, telephone and card fields are always masked. You can relax masking for chosen elements; agree that with your security team first.
How are synthetic tests and RUM billed?
Datadog counts API tests per 10,000 runs, browser tests per 1,000 runs and RUM per 1,000 sessions. Frequency and the number of locations multiply runs, so estimate before you schedule every test every minute; see Datadog pricing: what drives the bill.
Next
Related guides
Next step
Plan monitoring for your customer journeys
Tell us which customer-facing services you run, the journeys that matter most and how users sign in. A specialist from the Riyadh team replies on Saudi working days, in Arabic or English.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia