> ## Documentation Index
> Fetch the complete documentation index at: https://docs.openops.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Investigating Workflow Runs

> How to troubleshoot and debug workflow runs

export const NarrowImage = ({src, alt, widthPercent}) => {
  const className = `narrow-image-${useId().replace(/:/g, '-')}`;
  const widthRule = widthPercent ? `width: ${widthPercent}%;` : '';
  return <>
      <style>{`
        .${className} {
          max-width: 75%;
          ${widthRule}
        }
        @media (max-width: 768px) {
          .${className} {
            max-width: 100%;
            width: auto;
          }
        }
      `}</style>

      <img className={className} src={src} alt={alt} />
    </>;
};

If a workflow didn't execute the way you expected it to, you can investigate what went wrong by viewing the history of workflow runs. You can do this [from the **Runs** view](#finding-a-run-from-the-runs-view) or directly [from the workflow editor](#finding-a-run-from-the-workflow-editor).

## Finding a run from the Runs view

Click **Runs** in the OpenOps main menu.

This opens the list of all runs across all your workflows, with the most recent runs shown first:

<img src="https://mintcdn.com/openops-ecb4f397/3bUWmSy1RNUzlV_0/images/runs-default.png?fit=max&auto=format&n=3bUWmSy1RNUzlV_0&q=85&s=74b11d54700cd4a53c48ee6c96cca7a6" alt="The list of all workflow runs" width="3324" height="1855" data-path="images/runs-default.png" />

You can filter the list by workflow name, run status (succeeded, failed, paused, timeout, etc.), type (triggered, manual run, test run), or a date range:

<img src="https://mintcdn.com/openops-ecb4f397/3bUWmSy1RNUzlV_0/images/runs-filters.png?fit=max&auto=format&n=3bUWmSy1RNUzlV_0&q=85&s=06aff3e93e87680776380e83746b7e15" alt="Workflow runs with filters applied" width="2560" height="1049" data-path="images/runs-filters.png" />

When you've found a run you want to investigate, click on it. This will open the workflow editor in a view-only mode.

Alternatively, if a run is taking longer than expected or is stuck in a paused state, you can abort it by clicking the three-dot menu on the right and selecting **Stop Run**:

<img src="https://mintcdn.com/openops-ecb4f397/3bUWmSy1RNUzlV_0/images/runs-stop.png?fit=max&auto=format&n=3bUWmSy1RNUzlV_0&q=85&s=a5a6847c7c0a922ddeea772e3a6456c1" alt="Stopping a run" width="1814" height="769" data-path="images/runs-stop.png" />

## Finding a run from the workflow editor

If the workflow you want to investigate is already open in the workflow editor, click **Run logs** in the top menu:

<NarrowImage src="/images/workflow-editor-run-logs.png" alt="Run logs button" />

In the **Recent Runs** pane that opens on the left, click a run that you want to investigate. Failed runs are marked with the ❌ icon:

<NarrowImage src="/images/workflow-editor-recent-runs.png" alt="Recent Runs pane" widthPercent={65} />

This will open the selected run in the **Run Details** pane.

## Investigating in the Run Details view

In the **Run Details** pane, each workflow step will display a ✅ or a ❌ to indicate its execution status.

Click on a failed step to see its inputs and outputs. Explore the outputs to view the error message:

<NarrowImage src="/images/run-details-error.png" alt="Run Details pane with error details" widthPercent={50} />

To update the workflow to address the error, click **Edit** in the top-right corner of the workflow editor. This switches the editor from view-only mode, enabling you to select the problematic step and modify its properties.

## Changing the default timeout

By default, OpenOps times out if a workflow runs for more than 10 minutes. This applies to both scheduled runs and test runs.

If you build long-running workflows, you may want to extend the default timeout. To do this, open the `.env` file in your OpenOps installation directory and add a new environment variable named `OPS_FLOW_TIMEOUT_SECONDS`. Set its value to the desired timeout in seconds — for example, `900` for 15 minutes or `3600` for 1 hour.

After making any changes to the `.env` file, restart the OpenOps containers:

```shell theme={null}
sudo docker compose down
sudo docker compose up -d
```