Uptime, synthetic and real-user monitoring: which website checks matter?

Start with the business journey

List the tasks people must complete: open a product page, submit an enquiry, sign in or finish a booking. For each task, name the system and team responsible. A homepage response is useful evidence about one address; it does not establish that the entire customer journey works.

For a fictional repair company, the critical journey ends when an appointment request appears in the scheduling system. A form can display a success message even if a later integration fails. Define where the monitoring evidence should stop and where another operational check needs to take over.

Use uptime checks for narrow availability questions

A basic availability check can ask whether an endpoint responds with an expected status or content. Specify the actual condition, location and interval. A check against a cached homepage may observe a different part of the system from a check against the application handling new submissions.

Treat an alert as a signal to investigate the defined condition. Do not automatically interpret every failed probe as a global outage or every successful probe as proof of a healthy customer journey. DNS, certificates, access rules and regional routing can affect an individual probe without explaining the whole incident.

Use synthetic journeys to exercise a task

Datadog’s browser-testing documentation describes scheduled scenarios across configured locations, browsers and devices. These tests can inspect conditions along a defined path rather than only opening one URL.

For the repair company, a synthetic journey could open the form, enter harmless test data and confirm the expected result in an approved test route. Decide how test submissions are identified and cleaned up. Avoid generating real appointments, charges or customer messages as an accidental effect of monitoring. Keep credentials and captured evidence within the organisation’s approved controls.

Use RUM to investigate actual visitor experience

Datadog’s RUM overview describes information about actual sessions, performance, actions and errors in instrumented applications. This complements a scheduled scenario because visitors use different devices, networks and paths.

RUM coverage depends on the instrumentation, sampling and collection settings. Absence of a recorded error does not prove that nobody encountered one. Review data collection and privacy settings before deployment, including any replay capability. A performance report should be interpreted with the population it actually observes, rather than presented as a complete record of every visitor.

Compare the signals side by side

The appropriate combination depends on business impact and operating capacity. Start with a few important checks somebody can investigate. A large collection of ownerless alerts can create more noise than useful coverage.

Set alert conditions and ownership deliberately

Decide how long a condition must fail, whether several locations are relevant and who receives the alert. Document planned maintenance and how recovery is recognised. Choose conditions based on the task’s impact, not simply the most sensitive setting available.

Keep enough evidence to investigate the failure: time, check version, location, observed condition and relevant application release. Avoid putting private customer data into alert messages. When a test fails after a website redesign, inspect whether the application broke or the test is following an obsolete path before changing the alert threshold.

Retest the monitoring after application changes

A new sign-in screen, form step or integration can invalidate an old synthetic scenario. Include monitoring ownership in the release process and periodically test the alert route with a controlled event. Verify that somebody knows how to pause an inappropriate test and restore coverage afterward.

Research the Datadog and New Relic profiles, then use the staging guide when planning website changes. Monitoring is most useful when it connects an observable failure to an accountable response and a verified recovery.

Frequently asked questions