Actions should reject attempts to configure a single-CPU runner with a timeout of more than 15min

[craigfowler]

Why are you starting this discussion?

Product Feedback

What GitHub Actions topic or product is this about?

Actions Runner

Discussion Details

When using a GitHub Actions runner with a Workflow that includes YAML like the following:

jobs:
  job_name:
    runs-on: ubuntu-slim
    timeout-minutes: 30 # or any value above 15

I think that GH Actions should treat that YAML as invalid and respond with an error message. This is because single-CPU runners have a limit of 15 minutes on execution which cannot be overridden from configuration. The result is currently confusing to a developer if they are unaware of that 15 minutes limit. Their job is cancelled after 15 minutes, and the developer left wondering why, when they had explicitly configured a longer timeout.

These two settings: running on ubuntu-slim and a configured job timeout of above 15min are contradictory. This is why I believe that they should be treated as an error when validating the YAML.

Background/context

I am new to GitHub actions and have only begun using it in January 2026. That is - the ubuntu-slim runner already existed before I started using Actions. I missed the release announcement explaining its purpose; I didn't know it was a relatively new feature. I had picked ubuntu-slim for some of my OSS builds because I wanted to be a good citizen and avoid being greedy with resources. I started receiving timeouts after 15 min that I did not understand, because I had used YAML config a little like the example above. The easiest-to-find documentation about GH runners states that the timeout cap is 6 hours, so timeouts after 15 mins confused me.

It was not until later-on that I managed to find the documentation which states that ubuntu-slim works differently and has a 15 min timeout. Even that documentation note is some way down the page, after information which was irrelevant to me (regarding CPU architectures). This is why I had missed it first time around.

Having looked further afield to try and diagnose my problem, I retrospectively found the release announcement of a few months ago, which also states the purpose of ubuntu-slim more clearly. I now know that I have misused them, I have changed my builds to ubuntu-latest and my problems have gone away. It would have been far quicker to diagnose and understand my problem though, if GH actions had rejected my configuration and signposted to me directly to the appropriate documentation. An error message such as the following would have saved me a lot of time.

The timeout-minutes for a build which runs on ubuntu-slim may not be higher than 15 minutes
<link to the documentation page>

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[SyedShaheerHussain]

You’re right that, from a user’s point of view, runs-on: ubuntu-slim combined with timeout-minutes > 15 is effectively a contradictory configuration. Since the 15-minute limit on single-CPU (slim) runners is a hard platform constraint and cannot be overridden, allowing a higher timeout in YAML creates an expectation that simply cannot be met. When the job is then cancelled at 15 minutes, it feels like unexpected or inconsistent behavior rather than a documented limit being enforced.

From a UX and developer-experience perspective, early validation would be a big improvement here. Failing fast with a clear error (or at least a warning) during workflow validation — for example, “ubuntu-slim runners have a maximum execution time of 15 minutes” — would prevent exactly the kind of confusion you describe and significantly reduce time spent debugging.

Your point about discoverability is also well taken. The general Actions documentation emphasizes the 6-hour job limit, and the ubuntu-slim exception is easy to miss unless you already know to look for it or have seen the release announcement. Newer users, especially those trying to be resource-conscious, are very likely to fall into this trap.

Even if strict YAML rejection isn’t desirable for backward-compatibility reasons, a validation warning or a more explicit runtime message (rather than a generic timeout cancellation) would go a long way toward making this behavior clearer.

Overall, this is good feedback and a sensible suggestion. It’s not about misuse so much as about the platform helping users align configuration with non-overridable runner constraints.