You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
jobs.<job_id>.timeout-minutes description is misleading #7984
What part(s) of the article would you like to see updated?
jobs.<job_id>.timeout-minutes
The maximum number of minutes to let a job run before GitHub automatically cancels it. Default: 360
Additional information
The text isn't technically wrong, but it's misleading.
Yes, if you use a self-hosted runner, you can set a value that's larger than 360, but if you are using GitHub hosted runners, then this limit is actually a hard limit:
Job execution time - Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete.
6*60 = 360
Problems:
The text really should explain that 360 is a hard max for GitHub runners explaining that people using GitHub runners can only reduce the limit (to prevent throwing away GitHub minutes, or GitHub billable minutes).
Why does one page use 360 minutes while the other list 6 hours? Sure, they're technically equivalent, but by using different units, it makes searching for a value in the other document hard.
The maximum number of minutes to let a job run before GitHub automatically cancels it. Default: 360
If the timeout exceeds the job execution time limit for the runner, the job will be canceled when the execution time limit is met instead. For more information about job execution time limits, see "[Usage limits, billing, and administration](/actions/reference/usage-limits-billing-and-administration#usage-limits)."
You or anyone else is welcome to open a PR with this addition.
Although you are correct that changing 6 hours to 360 minutes in Usage limits, billing, and administration would be more consistent across articles, I recommend keeping it as 6 hours so that unit comparison within the article is easier (e.g. job limit is 6 hours, and workflow limit is 72 hours).
It isn't technically wrong, but it's too easy for someone to misparse.
(I'm currently dealing with another project which is failing to properly parse an RFC.)
You need to include text that hints that the jobs value is clamped by a second value. Or similarly that if the value exceeds the second value, it is ignored and that second value is honored instead.
It isn't technically wrong, but it's too easy for someone to misparse.
(I'm currently dealing with another project which is failing to properly parse an RFC.)
You need to include text that hints that the jobs value is clamped by a second value. Or similarly that if the value exceeds the second value, it is ignored and that second value is honored instead.
Thanks for this input, @jsoref. Could you open a PR or comment with specific text that you think would be clearer? In the interest of moving this forward, I will merge @lucalves 's PR, but we are open to additional improvements.
Activity
jsoref commentedon Jul 6, 2021
Confused user: https://github-community.bar.bot.cd/t/workflow-was-terminated-after-360-minutes-but-config-have-set-timeout-minutes-to-600/188631
ramyaparimi commentedon Jul 7, 2021
@jsoref Thank you for opening this issue 👍 I will triage it for review ⚡
skedwards88 commentedon Jul 13, 2021
Thanks for opening this issue! I agree that we should mention time limits here. The text in Workflow syntax for GitHub Actions - GitHub Docs could be changed to something like:
You or anyone else is welcome to open a PR with this addition.
Although you are correct that changing 6 hours to 360 minutes in Usage limits, billing, and administration would be more consistent across articles, I recommend keeping it as 6 hours so that unit comparison within the article is easier (e.g. job limit is 6 hours, and workflow limit is 72 hours).
lucalves commentedon Jul 19, 2021
Hello, I opened #8362 to solve this.
jsoref commentedon Jul 19, 2021
@skedwards88, @lucalves: I wouldn't write it that way.
It isn't technically wrong, but it's too easy for someone to misparse.
(I'm currently dealing with another project which is failing to properly parse an RFC.)
You need to include text that hints that the jobs value is clamped by a second value. Or similarly that if the value exceeds the second value, it is ignored and that second value is honored instead.
skedwards88 commentedon Jul 20, 2021
Thanks for this input, @jsoref. Could you open a PR or comment with specific text that you think would be clearer? In the interest of moving this forward, I will merge @lucalves 's PR, but we are open to additional improvements.