Getting started

ScoutSentinel proves, from the outside, that a customer capability works. This guide takes you from an empty organisation to a running Watch with evidence in about ten minutes.

Before you begin

• A public URL for the journey you want to assure (for example a quote form or a checkout).
• A test account or test card if the journey needs one. Credentials are stored envelope-encrypted and never appear in evidence, logs or model prompts.
• Optional: a Slack channel or webhook endpoint for Events.

1. Create an organisation and environment

Sign up at app.scoutsentinel.com/signup. Every organisation starts with a Production environment; add Staging if you want to assure pre-production too. Environments scope Subjects, Watches and notification routing.

2. Describe the journey

Go to Journeys and choose New journey. Write the capability in plain language:

UK customers can get a travel insurance quote for two travellers and buy it with a test card, every five minutes, from London, Frankfurt and Sydney.

The composer discovers the entry points (homepage, forms, API calls observed during a guided run) and proposes a Watch: deterministic steps, assertions, a schedule and a location policy. Nothing runs on a schedule until you approve it.

3. Review the plan

Open each step. You can edit selectors, add or remove assertions, change timeouts and mark which steps use a browser and which use HTTP or API probes. The plan is stored as a Watch version; later edits create new versions and the history is kept.

Assertions are the contract. Outcome assertions decide pass or fail (status code, visible confirmation, order number format). Behaviour assertions track material change (page structure, redirect chains, response shape). See the step DSL and assertions reference.

4. Run once, then activate

Choose Run now. The run appears under Runs with per-step timings, screenshots, HAR and logs. When you are happy, set the Watch to Active. Scheduled runs begin at the interval your plan allows.

5. Connect a destination

Under Integrations, add Slack, PagerDuty, email or a signed webhook. Events carry the failure boundary, what still works, confidence, coverage and evidence links. Configure the materiality policy on the Watch to decide what opens an Event: by default, two consecutive failing runs with the same failure boundary within 30 minutes; raise corroboratingLocations to require agreement from more than one location.

6. Read your first Event

When an Event opens, start with the failure boundary and the evidence list. Every artefact shows its hash, capture time and retention. Acknowledge the Event to stop repeat notifications; resolve it when the journey passes again, or let ScoutSentinel resolve it automatically after two consecutive clean runs (the autoResolveAfterPasses default).

Next steps

• Journeys, Watches, Observations, Events and Evidence: the object model in one page.
• Runner locations: what each location class can and cannot tell you.
• Synthetic traffic identification: how to allowlist our probes so bot protection does not turn a working journey into an unknown.