> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Watch a critical user journey

> Cover a journey such as sign-in or checkout from three sides: synthetic checks from outside, real users with RUM, and the backend with an SLO, and tie them to the status page.

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.

| Side | Tool | Catches | Misses |
| - | - | - | - |
| Outside | [Synthetic checks](https://docs.molesignal.com/en-US/synthetics.md) | Outages at any hour, even without traffic; expired certificates; DNS failures. | Problems that only some users, devices, or data hit. |
| Real users | [RUM](https://docs.molesignal.com/en-US/rum) | Slow pages, frontend errors, frustration, and what users really do. | Nothing when nobody uses the journey. |
| Backend | [APM SLOs](https://docs.molesignal.com/en-US/apm#service-level-objectives) | Errors and latency of the endpoints behind the journey, with an error budget. | Failures that happen before a request reaches the backend. |

## 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](https://docs.molesignal.com/en-US/synthetics.md#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](https://docs.molesignal.com/en-US/rum/browser-sdk.md) in the application:

* On [Performance](https://docs.molesignal.com/en-US/rum/performance.md), follow LCP, INP, and CLS at the 75th percentile for the pages of
  the journey.
* On [Frustration](https://docs.molesignal.com/en-US/rum/frustration.md), look for rage clicks, dead clicks, and error clicks on the
  steps of the journey.
* On [Errors](https://docs.molesignal.com/en-US/rum/errors.md), assign the issues of the journey to its team.
* Open [session replays](https://docs.molesignal.com/en-US/rum/session-replay.md) of failed journeys to see what users saw, with the
  [privacy settings](https://docs.molesignal.com/en-US/rum/privacy.md) that mask personal data.

Create [RUM alerts](https://docs.molesignal.com/en-US/rum/alerts.md) 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](https://docs.molesignal.com/en-US/apm#service-level-objectives) 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](https://docs.molesignal.com/en-US/apm#burn-rate-alerts): the fast burn
pages, and the slow burn warns.

## Tell customers

Create a [status page](https://docs.molesignal.com/en-US/status-pages) component for the journey, such as "Checkout". Connect it with
[publication automation](https://docs.molesignal.com/en-US/status-pages#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](https://docs.molesignal.com/en-US/reports.md) 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.

## Related guides

* [Synthetic monitoring](https://docs.molesignal.com/en-US/synthetics.md)
* [RUM](https://docs.molesignal.com/en-US/rum)
* [Status pages](https://docs.molesignal.com/en-US/status-pages)
* [Verify a release](https://docs.molesignal.com/en-US/best-practices/release-verification.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.