A run never ends half-finished: it completes, waits for an event, or fails into an exception queue with the reason attached.
Why teams switch
A partner endpoint times out at 2am, orders stop moving, and someone re-keys them by hand the next day. Flows replaces the cron job that fails overnight and the orders someone re-keys the next morning.
With Flows: every run completes, waits for an event, or fails into an exception with the reason attached, and your team is alerted by email, Slack, or webhook.
Durable runs and events
Runs execute on Temporal, the durable workflow engine. Every step records what it received and produced, so a run interrupted mid-step resumes where it was, and a run waiting on the real world can wait for days without anything polling.
order_createdAn order arrives from your store.
orderly.rateRates quoted across your carrier accounts.
orderly.label.purchaseFunds held, then the label is bought.
wait.eventParked on shipment.delivered for hours or days. Nothing polls.
shipment.deliveredSignal arrivesPOST /runs/{id}/signalYour tracking feed confirms delivery.
http.requestThe follow-up sends with the signal payload.
wait.event, the signal arrives, and the run resumes at the exact step it paused on.Waits and signals
A run can pause until an order ships, a claim is decided, or an external system calls back. The flow hands out {{ run.id }}, and whoever has the answer posts the event to that run. A wait can last up to 30 days; if the event never arrives, an exception opens instead of the run quietly disappearing.
Customer experience
Start a run when a shipment is created, park it on shipment.delivered, and send the follow-up only once delivery is confirmed. If the event never arrives, an exception opens instead of the run quietly disappearing.
shipment_createdwait.eventhttp.requestExceptions
Retry continues the original run from the step that failed, so steps that already succeeded are never done twice. Replay starts a new run from the first step on the latest published version, which is right after you changed the flow. Recovery lanes are configured in the designer.
A failed step opens an exception with the reason and keeps the run's place for 30 days. Fix the cause and retry from the failed step, or replay the run from the start.
Give any step a retry policy with backoff, and a handler lane of up to 20 steps that runs when it fails for good, then continues or fails the run as you choose. Both are set in the designer.
An exception on a step that moves money is raised as high priority, and when one fails in a scheduled flow the flow is paused so the schedule cannot keep failing.
Monitoring
Send new exceptions and stuck runs to email, Slack, or a signed webhook. A storm guard caps each channel so one bad night does not bury the inbox.
Runs that stop making progress are found and failed into an exception, and dedicated queues are checked for a live worker.
Finished runs and their step records are kept for 90 days on Launch, 180 on Pro, and 365 on Dedicated. Endpoint request records are kept for 90 days.
Reporting
Reliability you can show a client or an auditor, not just assert.
The reliability report gives each month's run success rate and endpoint availability for up to the last 12 months, with the worst day's p50, p95, and p99 run durations.
Figures come from daily rollups that are kept after finished runs and request records pass their retention window, so last quarter's SLA is still there when you need it.
The Orderly status page shows the Hub API and the Flows runtime. The watchdog updates the runtime's status automatically, and the Orderly team posts incidents there.
Flows Dedicated adds a single-tenant runtime with priority support and an SLA; see Flows pricing.
Under the hood
Enterprise integration is judged on the bad day. These rules are built into the runtime, so no flow, template, or rushed change can switch them off.
Purchase label holds the cost against your balance before the carrier is called. It and Schedule pickup can never be set to skip on error or be swallowed by a recovery lane.
Runs execute on Temporal, the durable workflow engine. Every step records what it received and produced, and a run interrupted mid-step resumes where it was.
A repeated endpoint request with the same Idempotency-Key returns the original result, and metering ids are derived from the run, so each run and request is counted exactly once.
A client flow touches only that client's connections, checked at publish, when a trigger matches, and again at every step. Every query is scoped to your organization.
Flow secrets for Basic auth and OAuth 2.0 client credentials are sealed with AES-256-GCM and referenced by name. No response ever returns a secret value.
Create claim opens a draft for your team to review. No flow files a claim with a carrier on its own.
Questions
The step retries on the policy you set. If it still fails, its recovery lane runs if you defined one, otherwise the run opens an exception with the reason and keeps its place for 30 days. Your alert channels hear about it by email, Slack, or signed webhook. Fix the cause and retry from the failed step, or replay the run from the start. A watchdog also finds runs that stopped making progress and fails them into exceptions, so nothing is stuck silently.
No. Purchase label holds funds before any carrier is called and fails the run if the balance cannot cover it. It can never be set to skip on error, and retries reuse the same idempotency key so a label is bought once.
A Wait for event step parks the run on a named event, such as shipment.delivered, with a timeout you choose. Every step can read the run id as {{ run.id }}, so the flow can hand it to the system that will answer. When your WMS, ERP, tracking feed, or a person in the dashboard posts that event to the run, it resumes at the wait step with the signal payload as its output. If the timeout passes first, the run fails into an exception you can retry.
Sleep through the night
Tell us where it breaks and who finds out. We will show you the flow, the exception it would open, and the alert your team would get.