Configure per-step retries with exponential backoff, add error branches for graceful degradation, and set up workflow-level failure alerts that fire before problems escalate.
Why Error Handling Belongs in Every Workflow
A workflow that works perfectly when everything goes right but crashes silently when something goes wrong is a liability, not an asset. In production, errors are inevitable: APIs return 500 responses, network connections time out, upstream data arrives in an unexpected format, and third-party services enforce rate limits. Without explicit error handling, these events cause your workflow to halt mid-execution, potentially leaving data in an inconsistent state or missing critical actions. Cotonity provides several mechanisms for dealing with errors gracefully: per-step retry configuration, step-level error branches, workflow-level catch handlers, and alerting integrations. Using these tools together means your workflows degrade gracefully and recover automatically whenever possible.
Configuring Retries on Individual Steps
Most transient errors — a momentary API outage, a DNS hiccup, a temporary rate-limit response — resolve themselves within seconds. For these cases, configure the retry policy directly on the failing step. Open the step's settings panel and navigate to the Error Handling tab. Set the maximum retry count (1–10) and choose a backoff strategy: fixed delay (retry every N seconds), linear backoff (delay increases by N seconds each attempt), or exponential backoff (delay doubles each attempt, with a configurable cap). Exponential backoff with a small amount of random jitter is the recommended default for calling external APIs, as it reduces the chance of multiple retried workflows all hitting the API at the same moment after a shared outage. Always set a retry budget that respects the total execution timeout of your workflow.
Adding Error Branches to Steps
When retries are exhausted and a step still fails, Cotonity can route execution to an error branch rather than halting the entire workflow. Enable the error branch on any step by toggling 'Continue on error' in the step's settings panel. A red error connector appears on the step card. Connect steps to this path to define what should happen on failure — for example, log the error to a database, send a Slack alert to the operations team, or attempt an alternative API endpoint. The error branch receives an 'error' context variable containing the HTTP status code, the response body, the number of retry attempts made, and the step name that failed. Use this data to make intelligent decisions in your fallback logic rather than simply sending a generic failure notification.
Workflow-Level Error Handling and Alerting
Some errors are unrecoverable at the step level and should escalate to a human immediately. Cotonity's workflow-level error handler fires whenever an unhandled error causes the workflow to terminate unexpectedly. Configure it in the workflow settings under Monitoring → On Failure. You can send an alert email, post a Slack message, create a Jira ticket, or call a custom webhook. Include the workflow name, the execution ID, and a link to the execution log in your alert payload so the on-call engineer has everything they need to investigate without searching. For critical automations, also consider setting a maximum execution duration alert — if a workflow that normally completes in under a minute is still running after five minutes, that is a signal something is stuck and worth investigating before it affects downstream systems.