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:

• Learn more: What are Synthetic Browser Transaction Steps?
• Tutorial: Splunk Synthetics Monitoring with Chrome Recorder

2. Group steps by purpose using transactions

Next, organize your steps into synthetic transactions. Each transaction represents a business-critical user flow, such as login or checkout.

This is a key part of designing with purpose. Instead of creating a single, massive test for an entire end-to-end workflow (like searching, adding to cart, and checking out), you should break it into separate, focused transactions. This allows you to isolate, test, and monitor each critical part of the user journey more effectively.

• Page-level metrics measure the performance of a single page load, which is valuable for spotting slow resources or rendering delays.
• Transaction-level metrics capture the performance of a multi-step workflow across one or more pages, allowing you to see how long it takes to complete an entire checkout, login, or report generation process, not just how fast each individual page loads.

By combining both perspectives, you can pinpoint whether an issue is isolated to a specific page or is caused by the cumulative steps in a workflow. Multiple transactions in a test let you measure separate workflows without losing context.

• Learn more: Transaction-level metrics in Splunk Synthetics
• Tutorial: Add synthetic transactions to your browser test

3. Feed passive monitoring and invoke services

Synthetic browser tests are interval based and run 24×7×365, so it does not matter if real users are actively interacting with your front end. This active monitoring approach means your critical user journeys are tested continuously, providing coverage even when user activity is low or nonexistent.

When configured correctly, synthetics allow you to detect issues impacting these journeys in real time. This enables proactive response so your teams can start investigating and remediating problems before customers report them.

Once an issue is detected, responders can confirm it by reviewing the filmstrip from the synthetic run. The next step is to identify the root cause and assess the impact, if any, to real users.

• Real User Monitoring (RUM) provides a view into actual user behavior so you can see who and how many are affected.
• From there, Application Performance Monitoring (APM) becomes essential for root cause analysis. APM service maps let you quickly understand backend health, dependencies, and bottlenecks, all in the context of the synthetic transaction that detected the issue.

Splunk ties this all together with deep links from synthetic runs directly into related RUM sessions and APM traces. This lets you follow the full journey from detection to impact assessment to root cause, in real-time, without losing context.

• Tutorial: Link synthetic spans to APM spans

Design your tests for success

Designing with purpose means building synthetic tests that are short, structured, and aligned to your most critical user journeys. By capturing realistic steps, grouping them into meaningful transactions, and integrating them with your passive monitoring tools, you create a feedback loop that is proactive, precise, and actionable.

If your synthetics setup can tell you what is broken, how it impacts users, and where to start fixing it (all before your first support ticket arrives) you have turned it into one of the most valuable assets in your observability stack.

Next step: Take one critical user journey in your environment and apply this approach. Use Splunk Synthetic Monitoring to record it, define transactions, and connect it to RUM and APM for end-to-end visibility. You can try it yourself right now with this free trial of Splunk Observability Cloud.