Skip to main content
Even well-designed workflows encounter failures — a downstream API times out, a referenced record no longer exists, or an action hits a rate limit. fsckmsft gives you granular control over what happens when a step fails so you can build resilient automations that degrade gracefully rather than silently dropping data.

​
What happens when a step fails

By default, when any step in a workflow throws an error or returns a failure response, fsckmsft pauses the workflow run at that step and marks the run status as Failed. The run does not continue to subsequent steps, and no data is lost — the run state is preserved so you can inspect it and retry. Simultaneously, fsckmsft sends an error notification to all workspace members who have the Workflow failure notification enabled. The notification includes the workflow name, the failing step, the error message, and a direct link to the failed run detail page.

​
Configure error notifications

  1. Go to Settings → Notifications.
  2. Under Automation, enable or disable Workflow step failure.
  3. Choose your preferred delivery channel: in-app, email, or Slack.
You can also set a per-workflow notification override:
  1. Open the workflow in the editor.
  2. Click Settings (the gear icon in the top-right).
  3. Under Notifications, choose Use custom settings and configure recipients and channels specifically for that workflow.

​
Per-step error handling

For fine-grained control, configure how each individual step behaves on failure.
  1. Click any step node on the canvas to open its configuration panel.
  2. Scroll to the On Failure section.
  3. Choose one of three behaviors:
The workflow run halts at the failed step. Subsequent steps do not execute. The run is marked Failed and an error notification is sent. Use this when downstream steps depend on the output of the failed step and proceeding without it would produce incorrect results.

​
Inspect failed runs in the error log

The Error Log gives you a complete history of every failed run across all your workflows.
  1. Navigate to Automation → Error Log.
  2. Use the filters to narrow by workflow, date range, step name, or error type.
  3. Click any row to open the Run Detail view, which shows:
    • A step-by-step execution trace with status indicators (✅ success, ❌ failed, ⏭ skipped).
    • The exact input payload each step received.
    • The error message and HTTP status code returned by the failing step.
    • The stack trace for code-execution steps.
Click Copy run ID in the Run Detail view to include it in a support request. The run ID lets the fsckmsft support team pull full diagnostic information for that specific execution.

​
Manually retry a failed run

If a step failed due to a transient issue — a network blip, a briefly unavailable external service — you can replay the run without re-triggering the original event.
1
Locate the failed run
2
Open Automation → Error Log and click the failed run you want to retry.
3
Choose a retry scope
4
In the Run Detail view, click Retry. You’ll see two options:
5
  • Retry from failed step — re-executes only the failed step and all subsequent steps, using the original inputs. Steps that already succeeded are not re-run.
  • Retry full run — re-executes the entire workflow from the trigger, using the original trigger payload.
    • 6
    Confirm and monitor
    7
    Click Confirm Retry. A new run entry appears in the log linked to the original, labeled Retry of run_xxx. Monitor its progress in real time from the Run Detail view.
    Manual retries count against your plan’s workflow run quota just like normal runs. If you need to retry many failed runs at once, use the Bulk Retry button at the top of the Error Log list view (select the runs you want, then click Bulk Retry).

    ​
    FAQ

    Yes. In each step’s configuration panel, expand Advanced and set a Step Timeout value (in seconds). If the step does not complete within that window, fsckmsft treats it as a failure and applies your configured On Failure behavior.
    Failed run logs are retained for 90 days on the Pro and Business plans, and 7 days on the Free plan. After the retention window, run logs are permanently deleted and cannot be recovered.
    It can, depending on the actions in your workflow. Steps that already succeeded before the failure are skipped when you use Retry from failed step, which reduces the risk. However, the retried steps themselves run again and will re-execute any external API calls. Review your downstream services for idempotency before retrying runs that include write operations.