timeout-minutes is not getting respected

[batbattur]

Problem

Sometimes the workflows are running into timeout-minutes limit and getting cancelled
even though the the total time for all steps didn't reach the timeout limit.

For example, the following workflow run was cancelled because it hit the timeout-minutes: 8 limit.
However, the total time for all of the steps was only around ~2minutes.

Note: I'm using Actions Runner Controller for my workflow. I noticed that the timer for the job/run starts
immediately before the steps start running (sometimes it takes a few minutes for the first step to start).

Question

I'm suspecting that, the timeout-minutes is using the initial queue start time for the job (maybe?) instead
of the time that passed from the first step.

How can I make the timeout-minutes to use the total time for the steps instead of the job queue start?

[Sagargupta16]

The timeout-minutes counts from when the job starts, not when the steps start executing. The gap you are seeing is likely due to:

1. Queue time counts toward timeout

If your self-hosted runner takes time to pick up the job (e.g., spinning up, waiting in queue), that time counts against the timeout. So if the job sits in queue for 6 minutes and your timeout is 8 minutes, your steps only get 2 minutes.

2. Setup steps are hidden

GitHub Actions runs setup steps before your visible steps:

• Checkout the runner application
• Set up the workspace
• Download actions (actions/checkout, etc.)
• Restore caches

These are not shown in the step timing breakdown but count toward the timeout.

How to diagnose

Look at the job timeline:

• Job queued timestamp vs Job started timestamp - this is your queue wait time
• The difference between job start and first step start is setup overhead

Fix

1. Increase the timeout to account for queue + setup time
2. Check runner availability - if runners are busy, jobs queue longer
3. Use a per-step timeout instead for more precise control:

steps:
  - name: Build
    timeout-minutes: 5  # per-step timeout
    run: npm run build

4. Monitor queue times - if you are using self-hosted runners, check if the runner pool is undersized

The job-level timeout-minutes is working correctly - it is just measuring a wider window than the visible step durations suggest.