Time out workflow `flow.timeout`

A timeout node commits a distinct timed-out outcome with the UTC deadline that caused it. Use it for an SLA, approval window, payment limit, or another boundary after which the process cannot continue. The node does not wait for a clock and does not poll current time. A normal graph first persists the same deadline in a wait node and enters timeout after wake-up.

Deadline and reason

deadline is a required date-time expression. Its result must include a timezone and come from stable input or a committed result. reason is an optional short business explanation that identifies which window expired. The deadline is part of the run conclusion and cannot be generated from a fresh clock read during replay. For a relative duration, first persist a base time and absolute result.

Incoming control uses in, and a connected value may arrive through the deadline data port. There is no outgoing control after the terminal event. When a workflow has several deadlines, use separate wait and timeout nodes so each node ID names one business boundary. If expiry still requires compensation, notification, or review, finish that work before committing timeout or delegate it to an independent child workflow.

Scheduling and observability

Test timezone offsets, already expired values, scheduler delay, duplicate wake-ups, process recovery, and cancellation races. Monitoring should record the business deadline, actual wake-up time, and terminal commit time separately, which identifies whether delay came from configuration, scheduling, or worker capacity. Keep credentials and full remote responses out of reason; place detailed diagnostics behind a controlled correlation ID.

Use it to record a business deadline that has expired. The deadline keeps the original UTC instant, while reason identifies the elapsed window.

Runtime behavior

Timeout closes the segment with a distinct timed-out outcome. A common graph first persists the same deadline in a wait node, then reaches timeout after wake-up.

Node contract

Type: flow.timeout
Role: Durable runtime command
Runtime binding: timeout
Durable identity: Defined by graph structure

Configuration properties

Property	Type and control	Default	Rules
`deadline`Deadline (UTC)	`dict`A3SFlowExpressionInput	`{"apiVersion":"a3s.dev/flow-expression/v1","expression":{"op":"field","path":"input.deadline"}}`	UTC deadline that caused the timeout.Required
`reason`Reason	`str`StrInput	`""`	Optional context for the timeout decision.Optional · Advanced

Ports

Direction	Port ID	Kind	Value types
Input	`in`In	control	`FlowControl`
Output	`deadline`Deadline	data	`DateTime`

Node JSON example

The CLI creates the same structure from manifest defaults. Canvas position, title, and selection are presentation data.

workflow.json

{
  "position": {
    "x": 320,
    "y": 160
  },
  "id": "example-flow-timeout",
  "data": {
    "deadline": {
      "apiVersion": "a3s.dev/flow-expression/v1",
      "expression": {
        "op": "field",
        "path": "input.deadline"
      }
    },
    "reason": "",
    "type": "flow.timeout"
  }
}

CLI usage

Inspect the installed manifest first, then create the node and validate the complete workflow. Every command emits JSON.

Terminal

a3s-flow node flow.timeout --pretty
a3s-flow new flow.timeout --id example-flow-timeout --pretty
a3s-flow validate workflow.json --pretty
a3s-flow compile workflow.json --pretty
a3s-flow digest workflow.json --pretty

Skill usage

The package includes the a3s-flow Skill. It queries the CLI catalog before creating, validating, compiling, and digesting a workflow.

Prompt

Use $a3s-flow to add the "flow.timeout" node to workflow.json, connect valid ports, and validate the result.

CLI usage · Skill usage

Operational notes

Do not decide timeout from a fresh clock read during replay.
The deadline must be a deterministic absolute instant.
Keep reason to a short business explanation.

#Time out workflow flow.timeout

#Deadline and reason

#Scheduling and observability