[Feature]: Support globalTimeout Configuration at the Project Level

[kathiresan-r-19912]

🚀 Feature Request

Currently, globalTimeout applies to the entire test run across all projects. However, in scenarios where multiple projects run in parallel, we may need different timeout limits for different projects.

For example, a Chromium-based project may require a longer execution time due to UI-heavy workflows, while a Firefox project may need a shorter timeout due to fewer test cases. Currently, the only workaround is to run each project separately with --global-timeout, which is not ideal for teams managing multiple projects in a single test suite.

Example

Allow globalTimeout to be set at the project level in playwright.config.js, similar to how timeout works for individual tests.

export default defineConfig({ projects: [ { name: 'chromium-tests', use: { ...devices['Desktop Chrome'] }, globalTimeout: 15 * 60 * 1000 // 15 minutes }, { name: 'firefox-tests', use: { ...devices['Desktop Firefox'] }, globalTimeout: 10 * 60 * 1000 // 10 minutes } ] });

Motivation

• Enables better test time management for different browsers or environments.
• Avoids the need for custom workarounds like globalSetup.js scripts.
• Prevents unnecessary test terminations when some projects need a longer timeout than others.

[dgozman]

@kathiresan-r-19912 How do you imagine this feature work when one project reaches its global timeout? Does the testing continue with other projects? Does everything fail? Please be more specific on the details.

[kathiresan-r-19912]

@dgozman Each project in playwright.config.js can have its own globalTimeout.

If a project reaches its globalTimeout, the playwright should stop executing tests for that project without affecting other projects.

Other projects should continue running until they either complete or reach their own globalTimeout.

[pavelfeldman]

Why was this issue closed?

Thank you for your involvement. This issue was closed due to limited engagement (upvotes/activity), lack of recent activity, and insufficient actionability. To maintain a manageable database, we prioritize issues based on these factors.

If you disagree with this closure, please open a new issue and reference this one. More support or clarity on its necessity may prompt a review. Your understanding and cooperation are appreciated.