What to monitor in an online shop: journeys, thresholds and alerts
Once it is clear that you need to monitor the purchase journey rather than whether the server is running, a practical question remains: exactly what should you monitor, how often, and at what value should an alert be sent? A checklist helps you configure timely alerts without unnecessary noise.
A common problem: monitoring checks only part of the purchase
The home page may be available even though search returns no results, the basket calculates the wrong total or the payment gateway fails to complete the order. If monitoring checks only the server response, the team often learns about such an error only from a customer.
The check should therefore reproduce the customer’s full journey and verify the expected outcome at every step. Set the scope and frequency according to the business impact, increasing the likelihood that the team discovers a critical problem sooner without allowing a less important fluctuation to create unnecessary noise.
Which journeys to monitor—prioritised by business impact
Monitoring should reproduce the customer’s journey. At regular intervals, a real browser follows it step by step. At each stage, it verifies not only the response status but also whether the expected elements are available on the page and can be used:
- Finding a product—search returns results, categories load, and the listing includes a price and an add-to-basket button.
- Basket—adding an item, changing its quantity and proceeding to the next step. The check verifies that the button exists and the total is correct; a redesign may change or remove the control.
- Registration and sign-in—including signing in as an existing customer, not merely displaying the form.
- Checkout—entering details and selecting delivery and payment. This deserves a separate check because it often contains several custom controls.
- Payment—completing the process through the gateway and returning to a confirmation. This step involves a third-party service you do not control.
- Confirmation and email—verifying that the order was actually created and the confirmation was sent.
Which threshold should trigger an alert
A simple “passed/failed” result is not enough. An online shop may work but be slow, which drives customers away just as effectively. Each step therefore needs a threshold:
- Step failure (the step cannot be completed)—we set the number of confirmation runs and the timing of the alert according to the risk. A single run responds faster; multiple runs reduce sensitivity to a one-off network fluctuation.
- Response-time threshold exceeded—we set the threshold according to what remains tolerable for the customer, typically a few seconds per step. We monitor a percentile, not a daily average that can conceal slow cases.
- Payment and sign-in receive stricter thresholds than a category listing—a failure closer to the money has a greater impact.
How often and where to send alerts
- We choose the interval according to the cost of an undetected outage: critical journeys such as payment and sign-in every few minutes, and less critical ones less frequently.
- We send the alert to the agreed channel—email, Slack or Teams—and configure the rules to limit unnecessary noise.
- Depending on the selected tool and configuration, a failure may include a screenshot, video or technical trace. This helps the team identify the step where the problem occurred.
What you gain
- A ready list of what to monitor and in which order—not “monitor everything”.
- Thresholds that also alert you to an agreed slowdown, not only a complete outage.
- An alert delivered to the agreed channel at a time determined by the interval and confirmation rules.
Next step
Would you like to apply this checklist to your online shop? Contact us—we will review your key journeys and propose scenarios, intervals and thresholds that increase the chance of detecting an outage before it has a more significant effect on revenue.