ScoutSentinelScoutSentinel
Menu

Synthetic monitoring for customer journeys · built for digital operations and resilience teams

Know when customers cannot complete a critical task—even when your systems look healthy.

Check that customers can get a quote, make a booking or complete a payment. ScoutSentinel’s synthetic monitoring runs the steps in a real browser, alerts your team when an agreed check fails, and keeps the screenshots, responses and timings. Start with one service and review the evidence with its owner.

Free 14-day pilot by invitation. No card required. Starter limits apply unless we agree a scoped one-service evaluation.

Illustration · our demo insurance site

At 04:20 the site's health check answers 200 OK while the Get a quote and buy a policy journey fails at step 4.

Uptime check

GET /api/health · 200 OK · 84 ms

Up

Get a quote and buy a policy

Step 4 of 8: Get quote button is shown

Failing

Event opened 04:25 after 2 failed runs · alert sent · demo-insurer.example

One journey, followed through a failure

What ScoutSentinel sees when a customer cannot buy

A check of “Get a quote and buy a policy” runs every 5 minutes against ScoutSentinel's demo insurance site. It is an illustration, not a customer: the site, the fault and the timings are ours. The wording of the event and the alerts is what the product writes.

1 · A working check

Every step passes, and each one is timed

The check does what a customer does, in a real browser: opens the site, starts a quote, enters a trip, gets a price, buys with a test card and waits for the policy reference. Each step has an assertion, so “passed” means the customer could finish, not that the page loaded.

Steps are written in plain words and proposed for you; you approve them before the check runs.

Get a quote and buy a policyRun at 04:15 · London · 8 of 8 steps passed · 8.73 s
Run passed
  1. 1

    Open the home page

    navigate https://demo-insurer.example/

    Passed1.24 s
  2. 2

    Start a quote

    click [data-testid=home-cta]

    Passed610 ms
  3. 3

    Enter trip details

    select destination · fill dates · fill travellers

    Passed1.83 s
  4. 4

    Get quote button is shown

    expect elementVisible [data-testid=get-quote]

    Passed90 ms
  5. 5

    Get a price

    click get-quote · expect elementVisible [data-testid=quote-price]

    Passed1.42 s
  6. 6

    Buy the policy

    click [data-testid=buy-now]

    Passed880 ms
  7. 7

    Pay with the test card

    fill card from secret · click [data-testid=complete-purchase]

    Passed2.35 s
  8. 8

    Policy confirmed

    expect elementVisible [data-testid=order-ref]

    Passed310 ms

2 · A detected failure

The quote step fails. Uptime still reads healthy.

At 04:20 the “Get quote” button is gone. The page still loads in a quarter of a second and the health check still says ok, so an uptime monitor reports nothing. The check stops at step 4 of 8: no customer can get a price, so none can buy.

At 04:20, an uptime check of demo-insurer.example reads healthy while the Get a quote and buy a policy journey fails at step 4.

What an uptime check sees

Up

demo-insurer.example · 04:20

  • GET /api/health{"status":"ok"}200 OK84 ms
  • GET /Home page loads200 OK212 ms
  • GET /quoteQuote page loads200 OK236 ms

Every page answers, quickly. A dashboard built on these reads green.

What a customer can do

Cannot complete

Get a quote and buy a policy · 04:20

Step 4 of 8: Get quote button is shown

expect elementVisible [data-testid=get-quote]

Result: element not visible after waiting 5 s

The quote page loads, but where the button should be it says “Quotes are temporarily unavailable online.” Nobody can get a price, so nobody can buy.

Get a quote and buy a policyRun at 04:20 · London · 3 of 8 steps passed · 8.68 s
Run failed
  1. 1

    Open the home page

    navigate https://demo-insurer.example/

    Passed1.24 s
  2. 2

    Start a quote

    click [data-testid=home-cta]

    Passed610 ms
  3. 3

    Enter trip details

    select destination · fill dates · fill travellers

    Passed1.83 s
  4. 4

    Get quote button is shown

    expect elementVisible [data-testid=get-quote]

    Failed5 s
  5. 5

    Get a price

    click get-quote · expect elementVisible [data-testid=quote-price]

    Not run–no time, not run
  6. 6

    Buy the policy

    click [data-testid=buy-now]

    Not run–no time, not run
  7. 7

    Pay with the test card

    fill card from secret · click [data-testid=complete-purchase]

    Not run–no time, not run
  8. 8

    Policy confirmed

    expect elementVisible [data-testid=order-ref]

    Not run–no time, not run

One failed run is not an alert on its own. The next run, at 04:25, fails at the same step, and an event opens: two consecutive failures is the default, and you can change it per check.

Steps 1 to 3 passed, so the site is up and the trip form works. The break is at one step, which is where the fix starts.

If our side cannot run the check, the run is recorded as unknown with the reason, and is not counted as a failure of your journey.

3 · The evidence

Before and after, the failing assertion and the timeline

The event puts the screenshot from the last passing run beside the first failing one, states what the step expected and what it found, and lays out every run, release and alert in order.

Step 4 screenshot: before and afterScreenshot evidence

Passed04:15last passing run

Failed04:20first failing run

The event pairs the last passing run with the first failing one, so the difference is the first thing you see.

The failing assertionFailed

Step
4. Get quote button is shown
Expected
expect elementVisible [data-testid=get-quote]
Observed
element not visible, after waiting 5 s
Event
Get a quote and buy a policy: step 4 "Get quote button is shown" element not visible (2 consecutive runs, cloudflare edge lhr)

Steps before it passed, so the failure is at this step, not the site as a whole. Depending on what the check captures, the page HTML, network log and browser trace from the same run sit beside the screenshot; each object is hashed when it is captured.

Timeline
  1. 04:12
    Release

    Release marker: quote-form deployed to production

  2. 04:15
    Passed

    Run passed, all 8 steps (London). Last passing run.

  3. 04:20
    Failed

    Run failed at step 4 (London)

  4. 04:25
    Failed

    Run failed at step 4 again (London)

  5. 04:25
    Event

    Event opened after 2 consecutive failures

  6. 04:25
    Alert

    Alert sent to the on-call email and Slack

  7. 04:55
    Tolerance

    Half of the service's 1 hour impact tolerance used; alert sent

UK time. Release markers come from your deployments (GitHub or the API) and sit on the same timeline, so a change just before the failure is easy to spot.

4 · The alert

What arrives, and what it names

On-call gets the task that failed, the step, where it was seen and a link to the event. Half an hour later the important business service “Customers can buy travel insurance online” has used half of its impact tolerance, and a second alert says so in those words.

Email to on-call · 04:25
Abridged

Get a quote and buy a policy: step 4 "Get quote button is shown" element not visible (2 consecutive runs, cloudflare edge lhr)

A high Event is open on Get a quote and buy a policy.

Step 4 (Get quote button is shown) failed: element not visible. Failing since 04:20 across 2 runs from cloudflare edge lhr.

Severity
High
Status
Open
Journey
Get a quote and buy a policy
Location
cloudflare edge lhr
Consecutive failures
2

View Event

The button opens the event: its steps, screenshots, timeline and every run behind it.

Slack · 04:25

[High] Get a quote and buy a policy: step 4 "Get quote button is shown" element not visible (2 consecutive runs, cloudflare edge lhr)

Journey Get a quote and buy a policy · Status Open

View Event

Impact tolerance · 04:55

Important business service "Customers can buy travel insurance online" has been disrupted for 30m: half of its 1h impact tolerance.

Raised again at 80% and when the tolerance is breached, through the same destinations.

Destinations: email (all plans), signed webhooks (all plans), Slack (Team and above) and PagerDuty (Team and above). Each alert names the journey; tolerance alerts also name the important business service, “Customers can buy travel insurance online”. Important business services start on Team.

For operational resilience

Measured the way you set impact tolerances

Your impact tolerances are written in customer terms: how long customers can be unable to buy a policy before harm. ScoutSentinel measures the same thing, from outside, with the evidence kept.

It supports your own self-assessment. It does not replace mapping or scenario testing, it is not a regulatory approval, and using it does not make a firm compliant.

  • Journeys under a service. Group the journeys that make up an important business service and set its impact tolerance. From Team.
  • Alerts before a breach. At 50% and 80% of the tolerance, and when it is breached, naming the service.
  • A report you can take to committee. Whether the service stayed within tolerance, the longest disruption, how much of the period was checked and what was not tested. From Business. See an example report.
  • Honest coverage. Runs we could not complete are counted as unknown, not as passes, so a quiet night is not mistaken for a good one.

Guides

Do it yourself, or let us run it

Practical guides to the failures uptime checks miss, with the steps to catch them yourself.

Pricing

Clear prices. Evaluate one important service.

Starter and Team are monthly plans. Business is priced per important business service and bought annually, and Enterprise is quoted. Browser allowances are published in the fair-use table, and every plan keeps the evidence. Ask about an invited, scoped evaluation of one service with reporting and sharing before choosing a paid plan.

Prices shown in GBP, excluding applicable taxes.

  • Starter

    £119per month

    Prices exclude VAT.

    Small SaaS or a single digital team

    No important business service reporting

    • Included: 5 checks, run as often as every 15 minutes
    • Included: Website and API checks
    • Included: 30 days of evidence
    • Included: Email, signed webhook and Jira Service Management alerts
    Apply for the pilot for Starter
  • Team

    Start with one service

    £399per month

    Prices exclude VAT.

    One important business service, monthly

    1 important business service with impact tolerance

    • Included: 25 checks, run as often as every 5 minutes
    • Included: Website and API checks
    • Included: 1 year of evidence
    • Included: Slack, PagerDuty, incident.io and GitHub
    Apply for the pilot for Team
  • Business

    £6,000per important business service per year

    Minimum 3 services: £18,000 a year, invoiced annually

    Prices exclude VAT.

    Three or more important business services, annual

    Priced per important business service, minimum 3

    • Included: Up to 100 checks across your services, as often as every minute
    • Included: Website, API, email and voice checks, within the fair-use budget
    • Included: 2 years of evidence
    • Included: Single sign-on (OIDC)
    Talk to us for Business
  • Enterprise

    from£40,000per year

    Annual agreement, quoted for your services and requirements

    Prices exclude VAT.

    Regulated or large organisations

    Priced by the number of important business services

    • Included: Custom check policy and service levels
    • Included: Metrics export (OpenTelemetry)
    • Included: Named support and onboarding
    Talk to us for Enterprise

Free 14-day pilot by invitation. No card required. Starter limits apply unless we agree a scoped one-service evaluation. When the trial ends, the organisation is suspended until you choose a plan: scheduled checks stop, and your journeys and checks stay in your account.

Prices exclude VAT. Full pricing, the plan comparison, fair-use budget and FAQ.

Trust

Privacy and security

Assurance is only as good as the evidence behind it and the care taken with your data. Each point links to the detail, including its limits.

Privacy

  • You decide how long we keep it. Set how long evidence, observations, the audit log and call audio are kept, within your plan, and a daily job deletes what has expired. An owner can delete the organisation: it closes at once and is permanently deleted 30 days later. Data retention.
  • Not used for advertising. We do not use your private monitoring data or account contact details for advertising, or sell them to advertising services. Who we share with.
  • Careful with AI. Known secret values and supported personal-data patterns are redacted before AI requests. Redaction has limits: use synthetic test data and avoid entering sensitive information. Screenshots, network archives and call audio are never sent. What the model sees.
  • No tracking without consent. The website sets no cookies of its own, and analytics start only if you accept them. Every provider that processes data for us is named, with 30 days' notice before we add one. Sub-processors.

Security

  • Verifiable evidence. As of 27 September 2026: evidence is hashed at capture, sealed into signed hourly checkpoints and timestamped under RFC 3161. A proof bundle for any item can be exported through the API and verified offline with our verifier, which we send on request during the pilot. Each layer and its limits.
  • Credentials protected, with stated limits. Stored test credentials are envelope-encrypted and decrypted only inside the check. Their known values are redacted from HTML, HAR, response bodies, logs and AI prompts, and the fields they fill are masked in screenshots. What is redacted and masked.
  • Your organisation, isolated. Organisation-scoped data with row-level security as a second line of defence. Evidence is never served from a public bucket: every download is checked and recorded. Evidence access.
  • Recognisable test traffic. Documented identifiers and a marker you control for allowlisting. Read the policy.

Start with one important customer journey

Apply for the pilot. Once your account is open, describe the journey and approve the check. Free 14-day pilot by invitation. No card required. Starter limits apply unless we agree a scoped one-service evaluation. When the trial ends, the organisation is suspended until you choose a plan: scheduled checks stop, and your journeys and checks stay in your account.