> ## Documentation Index > Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt > Use this file to discover all available pages before exploring further. # Monitor workflows > Monitor workflow runs with detailed step logs, run states, performance metrics, and debugging tools to keep your Ravenna automations reliable. Monitor workflow execution with detailed logs, performance metrics, and debugging tools to keep your automation running reliably. ## Run and step statuses **Run statuses:** | Status | Meaning | | --------------------- | ----------------------------------------------------------------- | | Pending | Queued, waiting for execution resources | | Running | Actively executing steps | | Completed | All steps finished successfully | | Completed with errors | Run reached the end of the workflow but at least one step errored | | Failed | Run halted because a step encountered an unrecoverable error | | Cancelled | Stopped manually or by system (e.g., Stop & Publish) | **Step statuses:** | Status | Meaning | | --------- | ----------------------------------------------------------------- | | Pending | Not yet started | | Running | Currently executing | | Completed | Finished successfully | | Failed | Encountered an error | | Skipped | Parent branch was skipped or condition was false | | Waiting | Paused on a wait step (Wait for Approval, Wait for Message, etc.) | *** ## What step logs capture Each step records: * **Resolved inputs:** The actual values used after dynamic references are resolved. * **Raw outputs:** The data produced by the step. * **AI reasoning:** For AI Decision Maker and Custom Prompt steps, the model's explanation for its output or decision. * **Duration:** Execution time for the step. * **Error details:** Error type, message, and context if the step failed. * **Retry attempts:** Number of retries and outcomes. *** ## Error types and retry behavior | Error type | Cause | Retries | Notes | | -------------- | -------------------------------------------------- | ------------------------------------- | ---------------------------------------------------- | | Validation | Missing fields, invalid formats, type mismatches | No | Fix the workflow configuration | | Integration | Connection timeout, API error, service unavailable | Yes (3 attempts, exponential backoff) | Check integration health and external service status | | Authentication | Expired credentials, insufficient permissions | No | Refresh credentials in integration settings | | Timeout | Step took too long to complete | Yes | Check external service performance | | Rate limit | Too many API requests | Yes (with backoff) | Reduce workflow frequency or stagger execution | Retries use exponential backoff: 1 second, then 2 seconds, then 4 seconds. After 3 failed attempts, the step fails permanently and the run is marked as failed. *** ## Retrying a run A run can be retried when its status is **Failed**, **Completed with errors**, or **Completed**. The **Retry** action appears in the row actions menu of the workflow runs table. Selecting it opens a dialog with up to three options: * **Retry with latest version** — Start a new run from the first step using the workflow's current active version. Only offered when the original run used an older version. * **Retry from failure** — Reuse outputs from successful upstream steps and rerun only the failed step(s). Requires that the upstream workflow shape and step configurations are unchanged between versions. Only offered when the run has at least one failed step. * **Retry from beginning** / **Rerun** — Start a new run from the first step using the same version as the original run. The new run is linked to the original through a parent run reference, which lets you trace retry chains. ### API `POST /workflows/runs/{runId}/retry` Body fields: | Field | Type | Notes | | ------------------ | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | `versionId` | string, optional | Workflow version for the new run. Defaults to the original run's version. Pass the workflow's active version ID to upgrade to the latest | | `retryFromFailure` | boolean, optional | If `true`, reuses successful upstream outputs and reruns the failed step(s). Otherwise the new run starts from the first step | Returns `{ runId }` for the new run. If the workflow shape upstream of the failed step changed between versions (a step was added, removed, or reconfigured), `retryFromFailure` returns an error. Fall back to starting from the beginning in that case. *** ## Skipping wait steps Workspace admins can skip Wait and Wait Until steps on a running workflow run. When a run is paused at a timer step, open the run details and click **Skip** on the waiting step to advance the workflow immediately. This is available only to workspace admins and only while the step is in a **Waiting** state. *** ## Debugging patterns **Workflow not triggering:** 1. Verify the workflow is published (not draft or paused). 2. Check trigger filters. Filters use AND logic, so overly specific filters may exclude the event. Test with relaxed filters first. 3. Confirm required integrations are connected (for integration-based triggers). 4. Check if another workflow is handling the same event first. **Action failing:** 1. Open the run log and find the failed step. 2. Check the resolved inputs. A common cause is a dynamic value reference resolving to null or an unexpected type. 3. Verify the integration is connected and credentials are valid. 4. Check external service status (Jira, Okta, etc. may be experiencing issues). 5. Test the same action with hardcoded values to isolate whether the issue is data or configuration. **Incorrect data in actions:** 1. Check the resolved inputs on the problematic step. Compare expected vs. actual values. 2. Verify the dynamic reference points to the correct upstream step and field. 3. Check for name collisions if multiple steps have similar names. 4. Review the trigger output to confirm the expected data was present in the originating event. **Slow execution:** 1. Check individual step durations to identify the bottleneck. 2. External API calls are the most common cause of slow steps. 3. Consider parallelizing sequential steps that are independent. 4. If a wait step is involved, verify the timeout configuration. *** ## Workflow attribution Ticket events include workflow attribution: the workflow name, run ID, and timestamp. Click the workflow badge to open the workflow run directly in a new tab. This lets you trace any automated ticket change back to the specific workflow run that caused it. Useful for debugging unexpected ticket changes, auditing automation impact, and understanding which workflows affect which tickets. *** ## Failure notifications Configure email and Slack notifications from the workflow Settings tab. * **Email:** Personal alerts with workflow name, run ID, and a direct link to the failure. Includes one-click unsubscribe. * **Slack:** Team notifications posted to a configured channel with formatted details and a link to run details. Notifications fire for runs that end in **Failed** *or* **Completed with errors**. Subject line, email body, and the Slack header reflect which terminal status the run reached. Set up failure notifications before relying on a workflow in production. Both channels work independently and can be enabled simultaneously.