Skip to main content
Customers do not care which service failed, only that checkout does not work. Pick the few journeys that matter most, and watch each one from three sides: a synthetic check that tries it from outside, real users who go through it, and the backend that serves it.

​
Name the journey and what success means

Write the journey as steps, for example: open the product page, add to cart, pay, see the confirmation. For each step, name the page or the endpoint, and what counts as success: the status, the content, and a time limit such as “payment confirmed within 3 seconds”. Keep names stable in every tool: the same view names in RUM, the same route templates in APM, and the journey name in the synthetic checks.

​
Probe it from outside

  1. Create an HTTP / API check for each critical API step, and a Browser check for the whole journey. See Create and publish a check.
  2. Assert what success means: a Critical assertion for the status and the confirmation text, a Warning assertion for the time limit.
  3. Run it from at least two locations, so one broken network path does not count as an outage, and set the failure and recovery thresholds to avoid flapping.
  4. Test revision, then Publish revision. Edits create a new draft, so the published check keeps running until the new one is proven.
Browser checks run at most once a minute; API checks can run more often. Use test accounts and test payment methods, never real customer data.

​
Watch real users

With the Browser RUM SDK in the application:
  • On Performance, follow LCP, INP, and CLS at the 75th percentile for the pages of the journey.
  • On Frustration, look for rage clicks, dead clicks, and error clicks on the steps of the journey.
  • On Errors, assign the issues of the journey to its team.
  • Open session replays of failed journeys to see what users saw, with the privacy settings that mask personal data.
Create RUM alerts on the figures that mean the journey is broken for many people, such as the error rate or a vital of its key page.

​
Track the backend with an SLO

Create an SLO on the endpoint behind the critical step, for example the payment endpoint, with Succeeds within a threshold and a latency threshold that matches the time limit of the journey. Add the burn-rate alerts: the fast burn pages, and the slow burn warns.

​
Tell customers

Create a status page component for the journey, such as “Checkout”. Connect it with publication automation to the synthetic checks and alert rules of the journey, with Manual approval at first: a confirmed failure becomes a draft update that a responder approves.

​
Review it every week

Copy the built-in RUM dashboard of the application with Create copy, add the synthetic results and the SLO, and schedule a weekly report to the team. Look at trends, not only at incidents: a vital that worsens a little each week is a release away from a broken journey.

​
Acceptance criteria

  • Each critical journey has at least one synthetic check from two locations, published and passing.
  • RUM covers the pages of the journey, and its errors have an owner.
  • The backend step has an SLO with burn-rate alerts.
  • The status page has a component for the journey, connected to its checks or rules.
  • A failure of the check in a test environment reaches the on-call person and creates a draft update.
Last modified on October 26, 2026