Business Flows: Multi-Step Sequence Monitoring
Track whether a sequence completes for one specific record, with hundreds of instances in flight at once. A single stalled order becomes an alert.
A business flow tracks whether a defined sequence of two to four steps happens in order and on time, for one specific record moving through a process, while many other instances run simultaneously.
The distinguishing feature is per-instance correlation. A monitor asks whether a job ran. A flow asks whether order 8821 specifically got from payment to fulfilment, while four hundred other orders are in flight.
One token for the whole sequence
You define the sequence once and get a single ingest token for it, not one per step. Each call says which step fired and which instance it belongs to.
The event_key identifies the step. The second field is named by whatever you set as the sequence's entity_id_field, so if your records are keyed on order_id, that is the field name you send. You are not forced into a generic key name that does not match your domain.
How stalls are detected
Each step carries a max_gap_minutes value, and this is the part worth reading carefully: it describes the allowed time since the previous step, not since the flow started.
That distinction is what lets you alert at step two of five rather than waiting for the whole process to time out. Authorisation should follow initiation within seconds; fulfilment might reasonably lag order creation by an hour. Both live in the same flow with appropriate limits.
| Step | event_key | max_gap_minutes | Measured from |
|---|---|---|---|
| 1 | checkout.started | n/a | Opens the instance |
| 2 | payment.authorized | 15 | Step 1 |
| 3 | order.created | 2 | Step 2 |
| 4 | fulfilment.requested | 60 | Step 3 |
An instance is stalled when it is overdue for its next step. Internally that is a self-join on step_order plus one, which means adding or reordering steps does not require rewriting any detection logic.
Instances are not unique per entity
The correlation table holds one row per in-flight run, matched on the sequence and the entity ID together. That pair is deliberately not unique, because recurring flows restart for the same entity repeatedly.
A dunning sequence runs again for the same subscription next month. A renewal flow runs annually for the same customer. If instances were unique per entity, the second run would collide with the first and one of them would be lost.
Completion notices are opt-in
Flows can send a one-time informational notice when an instance completes successfully. It is off by default, because most people want to hear about problems rather than receive a message for every order that worked.
A completion notice does not create an alert row, since there is nothing to acknowledge or resolve. It appears in the dashboard's completions panel, styled as a success rather than sitting in a problem log.
Plan limits
| Free | Starter | Team | Enterprise | |
|---|---|---|---|---|
| Business flows | 0 | 5 | 25 | Unlimited |
| Steps per flow | n/a | 2-4 | 2-4 | 2-4 |
| Instances in flight | n/a | Unlimited | Unlimited | Unlimited |
Flows are not available on the Free tier. If you want to try one, Starter is the entry point.
Choosing the gaps
Measure your real timings before setting limits. Take the 99th percentile of each gap over the last month and add margin, rather than guessing. A p99 far above the p50 usually means that step is already failing intermittently and nobody has noticed.
Worked examples: checkout to fulfilment, signup to activation, subscription billing and dunning. Concept: business flow monitoring.