Workflows

A workflow is a trigger plus up to 50 steps. Triggers live in workflows.trigger; a workflow holds up to 5.

• event {pattern}: RE2, anchored over {domain}.{resource}.{event}. The legacy events list still works.

• cron {expr, tz}: 5 fields, CRON_TZ=Zone prefix honored, one-minute resolution.

• manual {inputs: [{name, type, required}]}: run from the UI, or POST /v1/projects/{p}/workflows/{id}/runs with idempotency_key and inputs.

Conditions: the old JSON tree, or a JSON string holding a CEL expression (variables event, event_type, steps, inputs; cost limit 10,000; compile errors carry line and column). A step may carry if (CEL); the switch action jumps forward by a CEL value.

Actions added: run_query, create_incident, acknowledge_alert, set_maintenance, notify_channel, plugin:<name>.<action>, and http_request with runner: <name> (or script: <name>).

Templates: GET /v1/workflow-templates, POST /v1/projects/{p}/workflows/from-template/{id}; instances start disabled and hold REPLACE_ME where you must choose a receiver, channel or schedule.

Private runner: an org admin registers one with POST /v1/orgs/{org}/workflow-runners (token shown once). wt-runner (WT_API_URL, WT_RUNNER_TOKEN, optional -config listing allowed scripts) polls outbound only, runs 4 steps at a time with a 60 s timeout. The server never sends a command line. Runner steps accept plain header values only.

Limits: 50 steps, 15 min per run, 5 triggers, 60 runs/min per workflow, 50 concurrent runs per org, 256 KiB event payload (capped / rate_limited run states).