Debugging Workflows
Diagnose and fix workflow failures using execution logs, step inspection, and common error patterns
When a workflow fails, the execution log tells you exactly which step failed, what input it received, and what error occurred. This guide covers the debugging process and common failure patterns.
Debugging Process
1. Find the Failed Step
Open the run in the visual builder or query the Runs API. The failed step has status: "failed" with an error message:
{
"id": "create-invoice",
"status": "failed",
"error": {
"code": "INTEGRATION_ERROR",
"message": "QuickBooks: Customer not found for ID cus_missing",
"step": "create-invoice"
}
}2. Check the Step Input
The input field shows exactly what data reached the step. Common issues:
- Template variables resolved to
nullorundefined - Upstream step output was in an unexpected format
- Data type mismatch (string vs number)
3. Check Upstream Steps
Walk backward through the execution log. If a Transform step produced unexpected output, the issue is in the transform mapping, not the downstream step that consumed it.
4. Fix and Re-run
After identifying the issue, update the workflow and run it again with the same input.
Common Error Patterns
Template Variable Errors
Symptom: Step receives null or undefined instead of expected data.
Cause: The template variable references a step that does not exist, or the output field name is wrong.
// Wrong: step name mismatch
"to": "{{steps.fetchCustomer.output.email}}"
// Correct: matches the actual step ID
"to": "{{steps.fetch-customer.output.email}}"Connection Expired
Symptom: Integration step fails with 401 Unauthorized or Token expired.
Fix: Re-authenticate the connection in the Connections panel. OAuth tokens expire periodically and need refreshing.
Rate Limiting
Symptom: Integration step fails with 429 Too Many Requests.
Fix: Add a Wait block before the integration step, or reduce the concurrency of parallel loops. Most APIs allow 100-300 requests per minute.
Timeout
Symptom: Step fails with TIMEOUT error.
Fix: Increase the step timeout in the configuration. For long-running operations (browser automation, large data extracts), set timeouts of 60-120 seconds.
JSON Parse Error
Symptom: Agent block returns text that cannot be parsed as JSON.
Fix: Add an output schema to the Agent block. This constrains the model to return valid JSON matching your schema.
Missing Required Fields
Symptom: Integration step fails with 400 Bad Request -- required field missing.
Fix: Check the step input in the execution log. Ensure all required fields are populated via template variables or static configuration.
Debugging Agent Blocks
Agent blocks can be tricky because the output depends on the AI model. Common debugging steps:
- Check the system prompt -- Is it specific enough? Vague prompts lead to inconsistent output.
- Check the input data -- Did the upstream block pass the expected content?
- Check the output schema -- Is it valid JSON Schema? Does it match what you expect?
- Lower the temperature -- Set to 0 for deterministic output during debugging.
- Check token limits -- If output is truncated, increase max tokens.
Debugging Stagehand (Browser) Blocks
Browser automation failures are often caused by page changes or timing issues:
- Use screenshots -- Add a
stagehand.screenshotstep before and after the failing action. - Increase timeouts -- Set
timeoutMsto 60000 or higher for slow-loading pages. - Check the instruction -- Be specific: "Click the blue Download PDF button" is better than "Click download."
- Enable agent fallback -- Set
agentFallback: trueso the system switches to autonomous agent mode when a simple action fails.
Using the Run Inspector
The visual builder includes a run inspector that shows:
- Step timeline -- Visual representation of step execution order and duration
- Input/Output panels -- Raw JSON for each step's input and output
- Error details -- Full error message, stack trace (when available), and retry history
- Template resolution -- Shows how template variables were resolved
The run inspector is available for all runs, including completed and failed runs. Open it from the Runs panel in the sidebar.
Best Practices
-
Start small. Test workflows with a single step before building the full chain. Verify each step produces the expected output.
-
Use the Transform block for data inspection. Add a Transform block to log intermediate data during development. Remove it before deploying.
-
Set up error notifications. Add a Condition block that checks for failures and sends a Slack or email alert.
-
Keep workflows focused. A workflow that does one thing well is easier to debug than a workflow that does ten things.