Journey monitoring
Catch the broken customer step before it stays invisible.
Give Steplatch an ordered form, checkout, or booking path with expected and actual observations. It stops at the first mismatch, opens an incident only after the same step fails twice, and records recovery only from later passing runs.
Sign in and you go straight back to the Steplatch conversation. Work happens in chat. This page never asks for your card details or email address.
FIRST RESULTA synthetic checkout or booking journey run with every step result, the first failure evidence, and separate recovery proof when resolved
01 / AUTHOR THE PATH
Bring an ordered path, not a live card.
Teams that need forms, checkout, and booking journeys tested as real step sequences with recovery evidence.
- 01
An ordered journey with expected observation per step
- 02
Actual observations from a synthetic checkout or booking run
- 03
Recent run history and, after a repair, later passing runs
02 / THREE COMMANDS
Uptime scores hide the first broken customer step. A later page can look fine after an earlier timeout, and a verbal “it works now” is not recovery.
- 01diagnose
diagnose walks steps in order and stops at the first actual/expected mismatch.
- 02decide
decide opens an incident only after two consecutive failures at the same step.
- 03recover
recover keeps passing run ids in input order and requires two passes before recovered.
WHAT THE BOARD RETURNS
Recovery is a later stamp, not a verbal all-clear.
status=failed plus the first mismatched step, or status=passed
open_incident, close_incident, or observe from consecutive runs
verified passing run ids, recovered_at, and recovered or not_proven
CONTROLLED PACKAGE EVAL
Three synthetic cases were scored against the delivered script.
Catalog evidence from eval-tasks/critical-path-monitor. These are not production booking or payment outcomes. environment=synthetic.
- diagnose
- failed_step=create_paymentexpected=test_payment_created · actual=timeout
- decide
- action=open_incidenttwo consecutive submit_form failures
- recover
- status=recoveredverified_run_ids RUN-8, RUN-9 · recovered_at 2026-07-14T10:20:00Z
- Incident
- INC-9 · checkout-demoverified_run_ids keep input order
YOU STILL HOLD THE KEYS
Steplatch scores the observations you supply. It does not charge a real card.
For teams that need forms, checkout, and booking journeys tested as real step sequences with recovery evidence.
It does not
- Live payment charges or real customer credentials
- Treating a single acknowledgement as proof the path recovered
Before acting
- Synthetic runs must use approved test identities and avoid real payment data.
- A passing check proves only the defined path and region at that time.
BEFORE YOU AUTHOR A PATH
Questions
What do I need to start?
An ordered path with expected results and the actual observations from a synthetic run. The engine scores those records; it does not charge a real card.
When does it open an incident?
Only after two consecutive failures at the same step. A single timeout stays observe so a flaky run is not treated as an outage.
When is recovery proven?
After at least two later passing runs. The recovery record keeps those run ids and the last passing finish time. Acknowledgement alone is not recovery.
STARTER / MONTHLY
Starter
Billing appears inside the signed-in workspace. Card payment runs through Stripe Checkout.
US$19 per month
This landing page never captures card or email details.
Continue to workspace billing