Business Flow Monitoring: Checkout to Fulfilment
Four events, four time limits, one order ID tying them together. A stall at step two is invisible in any throughput graph.
Checkout is the flow most worth instrumenting first, because a stall leaves money taken and nothing delivered, and because every step crosses a system boundary where something can quietly stop.
The sequence
Define the steps as they exist in your system, not as an idealised diagram. The correlation key is the order ID, and every step has a time limit relative to the step before it rather than to the start.
| # | Event key | Max gap from previous | What a stall here means |
|---|---|---|---|
| 1 | checkout.started | n/a (opens the flow) | Nothing yet |
| 2 | payment.authorized | 15 minutes | Abandoned cart, usually benign |
| 3 | order.created | 2 minutes | Charged, no order exists |
| 4 | inventory.reserved | 5 minutes | Oversell risk |
| 5 | fulfilment.requested | 60 minutes | Paid order never reaches the warehouse |
| 6 | shipment.created | 24 hours | Customer waiting, no tracking |
Step 3 carries the tightest limit and the worst consequence. Between authorisation and order creation the customer's money is committed and your system has no record of what it is for.
Step 2 is deliberately loose. People abandon carts constantly, and a stall there is normal behaviour rather than a fault. Alerting on it would generate noise that trains everyone to ignore the flow entirely.
Instrumenting it
Each step reports with the same entity ID. The monitor opens an instance at step 1 and closes it at step 6, alerting on any instance that goes overdue for its next step.
Call it after the work commits, not before. A step reported optimistically before a database transaction completes will report success for a step that then rolled back.
Why aggregate metrics miss this
At a 0.4% stall rate, a store processing 500 orders a day has two broken orders daily. On a throughput graph that is a flat line. In the support inbox it is two people whose money you took.
Error tracking does not catch it either, because nothing threw. Each service did its job; one message between two of them was lost, and neither end has a reason to complain.
Per-instance correlation is the only approach that surfaces it, which is the argument made in business flow monitoring.
Setting the gaps from real data
Measure before you choose. Take the 99th percentile of each real gap over 30 days and add margin, rather than picking round numbers that feel about right.
A p99 that is wildly higher than the p50 usually means the step is already failing intermittently and nobody has noticed, which makes this query worth running before you build anything.
What to do when one stalls
The alert should carry the entity ID, the step reached, and how long it has been stuck. That is enough for whoever picks it up to open the order and decide between completing it manually, refunding, or contacting the customer.
SensaCat tracks these instances individually and alerts per stalled entity rather than on an aggregate. Start free.