ScoutSentinelScoutSentinel
Menu

Interactive examples

See what a run and an Event actually look like

Explore the Buy online journey, compare passing and failing runs, then inspect the resulting Event. Step details are available in the page; replay and comparison controls require JavaScript.

Example 1

A replayable journey run

Seven deterministic steps, nine assertions, one browser probe and one API probe. Choose a run and press replay; the frame on the right describes what the probe saw at each step.

Buy online

Complete a purchase on shop.example.com

London, UK (Cloudflare edge) · started Passed
  1. Load homepage2.1s

    https://shop.example.com

    • HTTP status is 200passed
    • Search form is visible within 3spassed
    not started
  2. Accept cookies0.8s

    click: [data-testid=cookie-accept]

    • Step completed without errorpassed
    not started
  3. Search product4.2s

    type: Lisbon, 2 travellers, 14 nights

    • At least 1 result renderedpassed
    not started
  4. Enter traveller details12.6s

    fill: name, date of birth, email

    • Step completed without errorpassed
    not started
  5. Get quote7.3s

    POST /api/quotes → 200 in 1.3s

    • POST /api/quotes returns 200passed
    • Premium between £40 and £400passed
    not started
  6. Add to basket4.1s

    click: Add to basket

    • Basket total equals quotepassed
    not started
  7. Complete purchase10.8s

    test card 4242, expect confirmation

    • Payment request returns 2xxpassed
    • Confirmation number matches /^ORD-\d{8}$/passed
    not started
Total 41.9scf-edge · chromium 130 · probe 0.1.0
shop.example.com

Step 1 of 7

Adventure starts here

Search form visible, hero rendered, 0 console errors.

Not started.

Why timings matter
Latency assertions degrade a journey before it fails. Step 4 at 12.6 seconds is normal for this form; 30 seconds would open a medium-severity Event.
Why the run stops
A failed outcome assertion ends the run and records the failure boundary. Everything before it is evidence of what still works.
Runner identity
Every Observation records provider, region, browser and probe version, so this run is comparable with the same run a week later.

Example 2

The Event that correlation opened

Two failing runs from three locations met the materiality policy. Toggle the evidence between before and after to see the first visible symptom, and read the confidence reasons: they are there so you can disagree with them.

CriticalOpenOutcome eventOpened · evt_01J8Q1F7N2WC

Buy online: purchase cannot be completed from any tested location

Since 04:25 UTC the payment step of Buy online fails from London, Frankfurt and Sydney. The payment provider endpoint pay.example-psp.com/v1/payments answers 502 in 30 seconds on every attempt. Steps 1 to 6 succeed and the API quote endpoint is healthy, so the failure boundary is the third-party payment gateway, not shop.example.com itself.

Failure boundary

Step
Step 7 · Complete purchase
Where
POST https://pay.example-psp.com/v1/payments
Observed
HTTP 502 Bad Gateway after 30.1s (3 of 3 locations, 2 consecutive runs)
First seen
04:25:34 UTC from London

What still works

  • Steps 1 to 6 of Buy online (homepage, search, traveller details, quote, basket)
  • POST /api/quotes: 200 in 1.3s median from all locations
  • Sign in journey: healthy, last proof 04:30 UTC
  • Contact support (web form): healthy, last proof 04:28 UTC

Confidence

92%

  • 3 independent locations agree (London, Frankfurt, Sydney)
  • 2 consecutive runs per location, 10 minutes apart
  • Same failing request and status code on every run
  • No runner or platform errors in the window

Coverage

Tested

  • Cloudflare edge: London, Frankfurt, Sydney
  • Browser probe (Chromium 130) and API probe
  • Test card path only

Not tested

  • Apple Pay and PayPal paths
  • Mobile app checkout
  • Residential or carrier networks

Last refresh 04:31 UTC

Change context

No deployment marker on shop.example.com in the last 6 hours. Behaviour fingerprint for steps 1 to 6 is unchanged (stable).

Evidence

shop.example.com/checkout04:25:04Z
Pay £128.40
Checkout page before the payment attempt: card form and an enabled Pay £128.40 button, order total £128.40.

Step 7 at 00:00, before the payment request was sent.

  • Screenshot before payment (step 7, 00:00)sha256 3f9a1c…b27e · 184 KB · 04:25:04ZR2 · 1 year
  • Screenshot after error (step 7, 00:31)sha256 9d2e77…41ac · 177 KB · 04:25:35ZR2 · 1 year
  • HAR archive for the runsha256 c04b1f…e9d3 · 1.4 MB · 04:25:36ZR2 · 1 year
  • Response body from pay.example-psp.com (502)sha256 77aa0e…5c19 · 1 KB · 04:25:34ZR2 · 1 year
  • DOM diff: checkout before and aftersha256 e1b3c8…07fd · 8 KB · 04:25:36ZR2 · 1 year

Evidence is hashed at capture, never edited by the application, and downloaded through short-lived tokens with an audit row.

Timeline

  1. 04:10 UTCBuy online passes from all locations (last known good)
  2. 04:25 UTCLondon run fails at step 7 with 502 from payment gateway
  3. 04:26 UTCFrankfurt and Sydney runs fail with the same request and status
  4. 04:31 UTCCorrelation opens this Event; materiality policy met (2 runs, 3 locations)
  5. 04:31 UTCSlack #ops and PagerDuty notified with evidence links

Get this for your own journeys

Describe the capability in plain language. The first run and its evidence arrive within minutes; Events only when your materiality policy says so.

Join the pilot Request a free journey assessment