Workflow Reliability Features
The reliability layer around every Sarudo workflow — contract validation, in-place patching, silent-failure tripwires, dry-run previews, and idempotent migrations.
Why a Reliability Layer at All
Raw n8n 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.
This layer is not optional and is not an upgrade. Every workflow built by Sarudo gets it by default — the four templates in the Pre-Built Templates article already have it wired in. You would have to actively disable it to lose it.
Contract Validation at Activate Time
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.
Validation catching a typo
A workflow refuses to activate because of a field-name mismatch.
In-Place Patching
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 n8n 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.
Before the in-place PATCH was shipped, changing a workflow meant delete-and-recreate, which could briefly leave external callers pointing at a dead webhook URL. If you are aware of any older docs or habits that say "delete the workflow, recreate it with the fix", ignore them — the current pattern is patch in place.
Heartbeat Tripwire for Silent Skips
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."
Zero-match heartbeat in action
The daily drafter finds no approved rows and pings you.
Preview Before You Activate
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.
Idempotent Migrations
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.
If an incident fix was rolled out that touches an existing workflow on your instance, Sarudo will mention the migration name and apply it as part of the fix conversation — you do not need to track migrations yourself. But if you are curious, "list automation migrations" gives you the registry.