Skip to main content
GitHub Actions provides a built-in way to automatically terminate long-running workflows, jobs, or individual steps using the timeout-minutes setting. By default, a workflow is killed after 360 minutes (6 hours), but you can customize the timeout at both the step and job levels to prevent runaway executions and save minutes.

Default Behavior

Without any explicit timeout, GitHub Actions enforces a global 360-minute limit:
If any step (e.g., a stray sleep 6000s) runs longer than 6 hours, the entire workflow will be forcefully terminated.

Example: No Timeout Specified

This sample workflow accidentally includes a long sleep command with no timeout:
Without timeout-minutes, this workflow could run until GitHub Actions kills it after six hours.

Step-Level Timeout

To limit only one step—regardless of other steps—you can set timeout-minutes on that specific step:
In this configuration, Docker Run with Timeout will be canceled if it exceeds 1 minute.

Job-Level Timeout

Applying a timeout at the job level ensures the sum of all steps in that job respects the limit:
Here, if Step A and Step B together take longer than 5 minutes, the entire job is terminated.

Timeout Comparison

* Workflow-level timeout is fixed at 360 minutes by GitHub.

Demonstration

  1. Commit and push your updated workflow or trigger it with Run workflow.
  2. Monitor the Docker Run with Timeout step in the Actions UI.
  3. After the specified timeout, you’ll see an error like:
  4. Under Annotations, GitHub pinpoints which step or job exceeded its limit.
This approach helps you control runaway processes, optimize usage, and reduce unnecessary billing on GitHub Actions.

Watch Video