Workflow Reliability Features

Raw automation workflows are flexible and powerful, but they fail in a very particular class of ways: silent failures where the workflow thinks it succeeded even though it did nothing useful. A sheet filter that catches zero rows and moves on looks like a success. An HTTP call with a typo'd field name that returns "200 OK ignored unknown field" looks like a success. A cron that skips because the target sheet ID is stale looks like a success. None of these are actually dangerous in isolation — they are dangerous because they are silent. The reliability layer fixes that one class of problem: every workflow Sarudo builds ships with tripwires that turn silent failures into loud ones.

Before any workflow is activated, its HTTP Request nodes are checked against the Sarudo tool-server's OpenAPI schema. Every node's target URL must resolve to a known endpoint. The HTTP method (POST, PATCH, GET) must match what the endpoint expects. Required fields in the request body must be present. Unknown field names are flagged with a Levenshtein fuzzy-match suggestion ("you wrote `src` on the image section — did you mean `url`?"). If any of these checks fail, activation is refused with a specific error message naming the node, the field, and the suggested fix. This catches the class of bug where a workflow ran for weeks silently sending wrong payload shapes that the endpoint politely ignored.

When a workflow needs a change — a new cron time, a fixed field name, a different downstream endpoint — Sarudo patches it in place rather than deleting and recreating it. In-place patching preserves the workflow's ID, execution history, and connections, which means downstream references (webhooks, other workflows, external services pointing at the webhook URL) keep working. The PATCH endpoint accepts surgical per-node updates — you can change one field on one node without touching the other nodes — or full replacement of the nodes array if you are doing a structural rewrite. Either way, it is a single-call operation with a dry-run flag so the plan can be previewed before committing.

Every scheduled workflow emits a heartbeat at the end of every run with one of four outcomes: success (the intended work ran and produced output), skipped (the workflow ran but there was nothing to do — zero rows matched the filter, for example), partial (the work ran but the output was incomplete — LLM truncation, fractional failures), or failed (an error occurred). Heartbeats land in Telegram based on a simple rule: success with non-zero rows_processed is quiet (no notification), success with zero rows is treated as a bug signal and pings you, skipped always pings, failed always pings, partial always pings. This means you notice when a workflow has silently stopped doing useful work — it shows up in Telegram as a skip or zero-success ping, not as a quiet "everything is fine."

The preview endpoint walks a workflow and classifies every HTTP node by side-effect type. Dry-runnable nodes (endpoints that respect the X-Sarudo-Dry-Run header) can be previewed without running for real. Side-effecting nodes that are not yet dry-run-aware are flagged by name so you can decide whether to activate with confidence or refactor first. This is most useful when you are about to deploy something with real-world consequences (sending emails, posting to social, firing publish webhooks) and want a flight-check before committing. See the Dry-Run Mode article for what the preview actually returns.

When an existing workflow needs to be updated in the field (for example, a bug in the daily drafter was fixed, or a new column was added to the content-calendar sheet), the fix ships as a named migration patch. The migration registry contains a builder function per patch — the builder detects whether the patch is already applied and skips if so, or produces the list of node patches to apply if not. You can list available migrations, preview what a named migration would change, and apply one by name. The idempotence means it is safe to re-run the same migration and safe to apply migrations out of order — each migration is a self-contained unit.