Beyond application availability: How Ashnik used Elastic Synthetic Monitoring to validate business-critical customer journeys.

For an e-commerce company, its website and mobile app are not just technology platforms. They are the business. Every product search, every page view, and every click on the “Add to Cart” button represents a potential sale.

We all understand the importance of application availability, speed, and responsiveness. But there is another reality that businesses cannot afford to ignore: when a customer encounters a poor experience, they may not complain or report the problem. They may simply move to a competitor. The business may never know why that potential sale was lost.

What makes this particularly challenging is that the website may still appear perfectly healthy. The servers are running, the homepage loads, and traditional monitoring dashboards show everything in green. Yet a product search might be failing, or an item may not get added to the cart.

From an IT monitoring perspective, the application is available. From the customer’s perspective, the experience is broken.

This is why businesses need to go beyond monitoring application availability. They need to proactively and continuously verify that critical customer journeys are functioning as expected, ideally identifying problems before they affect more customers.

This is where Synthetic Monitoring plays an important role.

By simulating real customer interactions and validating the outcome of each step, synthetic monitoring helps businesses understand not just whether their digital applications are running, but whether customers can actually use them successfully.

In a recent customer engagement, our team at Ashnik used Elastic Synthetics to develop and test ten browser-based customer journeys and implement the customer’s synthetic monitoring solution. The solution is now live in production and the customer is using it to monitor selected business-critical workflows. The experience reinforced an important lesson: effective synthetic monitoring begins with understanding the business journey, not merely writing monitoring scripts.

1. Moving Beyond Application Availability

Traditional infrastructure and application monitoring provide essential visibility into the technology environment.

Infrastructure monitoring tells us whether servers and supporting systems are healthy. Application Performance Monitoring (APM) helps identify performance problems within application transactions and services. URL monitoring verifies whether a website or endpoint is reachable.

These capabilities remain important. However, none of them, on its own, guarantees that a customer can successfully complete an entire business transaction.

Consider a typical e-commerce journey:

1. A customer searches for a product.
2. The application displays matching products.
3. The customer selects a product and opens its details.
4. The customer adds the product to the shopping cart.
5. The cart reflects the correct product and quantity.

Each action may involve multiple application components, browser interactions, APIs, and backend services.

A successful HTTP response does not necessarily mean the expected business action succeeded. A search page might load but return incorrect results. A product page might appear, but its interactive elements may fail. An “Add to Cart” button might respond to a click without updating the cart.

From a monitoring perspective, the distinction is fundamental.

Application availability tells us that the system is responding. Business journey monitoring tells us whether the system is delivering the intended outcome.

Synthetic monitoring bridges this gap by executing predefined customer interactions through a browser and checking whether each important step behaves as expected.

2. The Customer Challenge: Translating Business Workflows into Monitoring

Our customer operated a business-critical e-commerce application with multiple interconnected workflows.

The customer already had conventional application availability checks and an existing base of functional test automation. However, the requirement was to establish meaningful, repeatable monitoring of critical customer interactions.

The challenge was not simply to automate browser clicks.

It was to identify which customer interactions mattered most to the business, translate them into reliable monitoring journeys, and make the execution results useful for operational investigation.

This involved answering several practical questions:

Our team at Ashnik began by reviewing the available automation assets and understanding the business workflows with the customer. We finalized the relevant monitoring use cases and mapped the sequence of interactions and checkpoints required to validate successful execution.

This business-first approach helped ensure that the monitoring would verify meaningful outcomes rather than merely report whether pages were accessible.

3. Engineering Synthetic Journeys Using Elastic

For the implementation, we used Elastic Synthetics with Playwright-based browser journeys.

Elastic Synthetics supports browser-level monitoring that simulates user interactions with web applications. Playwright enables these journeys to be expressed as automated browser actions, including navigation, clicking elements, entering information, and validating results.

Our team reviewed the existing functional automation flows and adapted the relevant interactions into synthetic monitoring journeys.

An important consideration was that functional test scripts are not automatically suitable for unattended operational monitoring.

A script that works during a controlled test may fail when executed repeatedly because of dynamically changing content, unreliable element selectors, page-loading behavior, or assumptions about application state.

We therefore focused on four engineering considerations.

Reliable browser interactions

Browser journeys need to work consistently across repeated executions.

We used appropriate element-selection strategies, handled page navigation, and accounted for dynamically loaded content. This reduces failures caused by the monitoring script itself rather than the application being monitored.

Meaningful functional assertions

A successful click does not necessarily indicate a successful transaction.

For example, a script should not stop at verifying that an “Add to Cart” button was clicked. It should validate whether the expected product was actually added to the cart.

These assertions distinguish business functionality failures from simple browser interaction failures.

Step-level visibility and diagnostic evidence

When a synthetic journey fails, knowing that the overall test failed is insufficient.

The monitoring approach was designed to identify the failed journey and step, capture execution details, and make diagnostic evidence—such as screenshots on failure—available for investigation.

Elastic Synthetics provides visibility into journey status, step execution duration, and errors, helping engineers narrow down where the failure occurred.

Monitoring efficiency

Browser-based monitoring consumes more resources than lightweight HTTP availability checks because it executes full browser interactions.

We therefore considered journey duration, execution frequency, and diagnostic-data collection to maintain a practical balance between monitoring coverage and resource consumption.

Through this approach, our team developed and tested ten Playwright-based browser journeys using Elastic.

These journeys form the technical foundation of the customer’s synthetic monitoring solution, which is now live and in use in production.

4. What Does a Synthetic Customer Journey Look Like?

To understand the value of this approach, consider an illustrative e-commerce journey involving product discovery and cart operations.

A browser-based synthetic monitor could execute the following sequence:

This is a representative example of the types of interactions considered in the engagement, rather than a specification of one particular delivered script.

Imagine that the website loads successfully and the product search works, but adding a product to the cart fails.

A conventional uptime monitor might continue reporting the website as available.

A synthetic browser journey with the appropriate cart assertion would identify the failed interaction and record the outcome.

The monitoring results could then help the application team understand which step failed, how long the journey took, and what diagnostic evidence is available.

This is where synthetic monitoring becomes particularly useful: it provides an independent, repeatable check of whether critical business functions are working as intended.

5. From Monitoring Results to Operational Action

Detecting a failed journey is only part of an effective monitoring strategy. The next step is helping the responsible team investigate and respond.

The monitoring approach implemented by Ashnik follows a straightforward model, with alerting available when configured:

Business workflows → Playwright browser journeys → Elastic Synthetics execution → Journey results and diagnostics → Dashboards and alerts where configured → Application/operations teams

The browser journeys interact with the customer-facing application and its supporting services. Elastic captures the resulting execution status, step durations, errors, and available diagnostic evidence.

These results can then be used for monitoring dashboards and failure-driven alerting.

Making alerts meaningful

Not every failed synthetic execution represents a genuine application incident.

Temporary connectivity problems, intermittent page-loading delays, and fragile test selectors can also cause failures.

An effective alerting strategy therefore needs to distinguish occasional test failures from persistent application problems.

For example, alert rules can be designed around repeated journey failures or suitable evaluation windows rather than triggering an operational incident for every isolated error.

When an alert is raised, it should help the team answer four questions:

This significantly improves the usefulness of monitoring compared with a generic notification that a website is unavailable.

For this engagement, Ashnik defined the alerting design and operational integration approach as part of the monitoring solution. With the solution now live in production, alerting can support operational response when alert rules, notification routing, and escalation ownership are configured and validated.

6. Finding the Right Balance Between Coverage and Cost

One practical lesson from the engagement was that synthetic monitoring frequency must be chosen carefully.

Unlike basic URL checks, browser journeys perform multiple user interactions. They may involve page navigation, dynamic content rendering, API calls, and functional validations.

Consequently, execution frequency directly affects the number of browser sessions and the monitoring resources consumed.

Our team evaluated execution intervals of 5, 10, and 15 minutes across the ten developed journeys.

The trade-off is clear: shorter intervals provide more frequent opportunities to discover a failure, while longer intervals reduce execution overhead.

However, the decision should not be based on resource consumption alone.

A failure in a critical purchasing workflow could have greater business consequences than an issue with a less frequently used feature.

For ongoing production monitoring, we therefore see value in aligning execution frequency with the business criticality of each journey, the desired failure-detection time, and the cost of monitoring.

Similarly, collecting detailed diagnostic evidence primarily when failures occur can help balance troubleshooting needs with monitoring overhead.

The objective is not to execute as many tests as possible.

It is to provide reliable coverage of the customer interactions that matter most, at a frequency appropriate to their business importance.

Conclusion: Monitor the Experience, Not Just the Endpoint

For digital businesses, application availability is essential—but availability alone does not guarantee a successful customer experience.

A website may be running, its infrastructure may be healthy, and its monitoring dashboards may show green. Yet a critical customer interaction could still be failing.

Synthetic monitoring helps address this blind spot by validating whether predefined business journeys execute successfully.

Our team at Ashnik translated this approach into a live production solution using Elastic Synthetics: starting with business workflows, building reliable Playwright-based browser journeys, defining meaningful functional assertions, and making execution results available for operational monitoring, with alerting supported where configured.

The important takeaway is not simply that ten browser journeys were developed and tested.

It is the shift in how application health is evaluated.

Instead of asking only, “Is my application running?”, businesses should also ask, “Can my customer successfully do what they came here to do?”

That is the real value of business-journey synthetic monitoring.