Getting Synthetics Right: How To Design Synthetic Tests with Purpose

Synthetic browser tests are one of the most powerful tools in your observability stack. When they reflect real user flows and backend interactions, these tests help teams to:

• Detect issues early.
• Simulate critical workflows during off-peak hours.
• Keep backend systems observable even when real users are not active.

This article covers Best Practice #1 in the Getting Synthetics Right Series : Design with Purpose.

What "design with purpose" means for synthetic tests

This best practice is about intentionally designing each synthetic test for clarity, measurability, and business value. Start by mapping short, critical user journeys that reflect the flows most important to your customers and your business. The key is to build journeys from authentic user interactions like clicks, form fills, and menu selections.

While it can be tempting to use shortcuts by directly calling a final URL, this approach bypasses the actual user experience. By simulating the full clickstream, your tests ensure that critical components like search bars and navigation menus are working as expected, not just that the final page loads.

Once you have your steps, group them into synthetic transactions so you can measure metrics like duration, requests, and size for each business-critical workflow. Finally, design your tests to invoke key backend services so that passive monitoring tools like RUM and APM continue to receive meaningful data, even during low-traffic periods.

We'll dive into each of these steps in detail, below.

Why this matters

Poorly structured synthetic tests can create noise, break for unrelated reasons, and leave you guessing about the root cause of a failure. By designing with purpose, you:

• Reduce flakiness by limiting scope to the steps that matter.
• Gain precision through transaction-level metrics that align with real workflows.
• Maintain backend visibility during off-peak hours by sending traffic to RUM and APM.
• Accelerate troubleshooting with clearer boundaries between test failures and actual application issues.

This approach turns synthetic monitoring from simple uptime checks into a powerful, always-on signal for both frontend and backend health.

Putting it into practice: How to design synthetic tests

1. Draft short, critical user journeys

Sit with a user or product manager to understand common and critical clickstreams. Document these clickstreams or record the session using a tool like Webex to map actual user behavior. Remember: the goal is to capture and understand the critical user journeys, not everything a user might do (we have RUM for that).

Examples of CUJs by industry:

With this understanding, you can build your synthetic test and take advantage of Splunk Observability Cloud's out-of-the-box support for importing from the Chrome Recorder to capture interactions directly from your browser and import them into Splunk. These short flows are built from steps that make up individual interactions like clicking a link, entering data, or selecting a value from a drop-down menu.

Once your test is live, Splunk captures a real-time video of the transaction execution and provides a filmstrip view with screenshots at 100ms, 500ms, or 1-second intervals. See this in action: