What Is Business Flow Monitoring?
Tracking whether a defined sequence of events completes in order for one specific record, while hundreds of others run at the same time.
Business flow monitoring tracks whether a defined sequence of events happens in the right order and within the expected time, for one specific record moving through a process. It is also called multi-step sequence monitoring or process monitoring.
The distinguishing feature is per-instance correlation. A cron monitor asks whether a job ran. A business flow monitor asks whether order 8821 specifically got from checkout to fulfilment, while four hundred other orders are in flight simultaneously.
The failure it is built for
Consider a checkout that emits four events: payment initiated, payment authorised, order created, fulfilment requested. Every service involved is healthy, every endpoint returns 200, and the throughput graph looks like a normal Tuesday.
One order reaches step two and stops, because a downstream queue rejected a malformed address. Nothing errored in a way anyone was watching, and the customer's money is authorised against an order that will never ship.
At a 0.5% stall rate this is invisible in aggregate. On a graph of two hundred orders an hour it is a line that does not move. It is also one customer every hour whose payment was taken and whose order does not exist.
How the correlation works
| Element | Purpose | Example |
|---|---|---|
| Sequence definition | The ordered steps that constitute one run | initiated, authorised, created, requested |
| Entity ID | Which instance an event belongs to | order_id, user_id, invoice_id |
| Event key | Which step of the sequence fired | payment.authorized |
| Max gap per step | Allowed time since the previous step | Step 3 within 5 minutes of step 2 |
| Instance state | One in-flight run, matched on entity ID | Open, completed, or stalled |
Each step carries its own time limit relative to the step before it, because the gaps are rarely uniform. Authorisation should follow initiation within seconds; fulfilment might reasonably lag order creation by an hour.
An instance is stalled when it is overdue for its next step, not when it is overdue overall. That distinction lets you alert at step two of five instead of waiting for the whole process to time out.
How it relates to distributed tracing
Both follow a unit of work across services, and the overlap is real. Tracing is oriented toward engineering questions such as which span consumed the latency, and it typically samples, keeping a fraction of requests.
Flow monitoring is oriented toward business completion and alerts on absence rather than on latency. Sampling defeats it entirely, because the one instance that stalled is exactly the one a sampler is likely to discard.
Process mining is a third neighbour, and it is retrospective. It tells you what your process actually looked like last quarter. It does not page anyone tonight.
Where it is worth the setup cost
It earns its keep where a partial completion is worse than a clean failure. Payment and fulfilment, onboarding and provisioning, KYC and approval chains, subscription dunning, and any multi-service handoff where money or access changes hands at step one and is only reconciled at step four.
It is overkill for a single job with no downstream steps. If the process is one action, a heartbeat answers the question at a fraction of the effort.
Related concepts
Compare with heartbeat monitoring for single-step jobs, webhook monitoring when the steps arrive as callbacks, and what is a silent failure for the broader category.