Journey assurance from the outside, with the evidence to prove it

Journeys and Watches

The primary object is the capability, not the script

A Journey is something a customer does: get a quote, buy online, sign in, submit a claim. Its status is derived from the Watches beneath it, and each Watch is your intent and policy for what must be true.

• Plain language in, deterministic plan out. The composer discovers entry points and proposes steps, assertions, schedule and locations. You approve before anything runs.
• Cheapest sufficient probe. HTTP, DNS and API checks when they prove the assertion; a browser only when rendering or interaction is required.
• Versioned and reviewable. Every edit is a new Watch version. Healing is off by default: review verified suggestions, or let an administrator enable verified automatic locator repairs.

Events

One Event, not fifteen alerts

Correlation groups related Observations, changes and assets, and opens an Event only when your materiality policy is met: by default two consecutive failing runs from two locations.

Failure boundary

The first step and request where the failure begins, with the status observed.

What still works

The steps and neighbouring journeys that pass, so you know the blast radius.

Confidence

Derived from agreeing locations, consecutive runs and consistency, with the reasons listed.

Coverage

What was tested, from where, with which probes, and what was not.

Unknown is a first-class state. A probe that could not run (runner error, capacity, bot protection) never opens a critical Event on its own and never counts as your outage.