Epic: User Configurable Workspace Timeouts (CLI command + user preference)

[svenefftinge]

Press Release

Gitpod users can now set any timeout up to 24 hours using the command line, or with a native integration in their favourite editors! To try out this feature, simply type: gp timeout set 1h in any running workspace to extend the workspace inactivity timeout of that workspace. To set your global user preference timeout, got to your use preferences and set the value that you want to apply for all future timeouts. Additionally, we've also made the editor timeout configuration optional, meaning that if you don't want a Gitpod workspace to timeout when you close your editor, you can now set

External Questions

Does this work for free users?

No, currently only users on a paid plan can extend timeouts.

Is the timeout respected / guarenteed?

No. A workspace has a maximum continuous session time of 36 hours.

Do timeout settings apply to running workspaces?

TBC

Can you set an admin preference for timeouts?

Not currently. This is something we plan to introduce as an organisation policy in the future.

Internal Questions

Why have a 24hr timeout limit?

24 hours is somewhat arbitrary, and we want to learn what users do with this. But, also the 24hr is based around a few infrastructure constraints. We have an undocumented 36 hour workspace session limit, that we need for doing workspace deployments, to allow us to upgrade workspaces. There are also some tokens within the workspace scoped to 24 hours that might break if a workspace runs longer than 24 hours (@akosyakov mentioned this - the supervisor token, which is revoked on workspace stop, renews on restart but doesn't refresh).

---

Context

Gitpod timeouts have historically been optimised mostly for cost reduction, to relieve users from any anxiety about leaving workspaces running forever and therefore creating unnecessary cost. Since Gitpod is ephemeral we want to encourage users to start new workspaces and manage the scaling of these workspaces to not incur unnecessary cost. As Gitpod moves towards a usage-based pricing model #9036 there is opportunity to review how Gitpod handles timeouts, giving more power to the user to decide what timeout configuration works best for them.

Currently, timeouts are fixed to 30min resp. 60min (+ 3h boost) for unlimited users. In some cases, however, there is a trade-off being made between the usability of Gitpod workspaces and cost management (through timeouts) as some users have use-cases where they want to have Gitpod workspaces open for longer, whereas other users would like to keep workspaces running, and are less cost conscious.

Use Cases

1. User is using an unsupported client without heart-beating (e.g. JetBrains Fleet)
2. User is running long-running tasks in workspaces and needs to leave workspace running (e.g data tasks)
3. When there is friction in re-setting up a closed workspace (e.g. re-setting up SSH commands, etc)
4. General convenience when going away from your computer for some time and returning

Acceptance Criteria (Implementation)

• User can set any timeout up to 24 hours from any client (VS Code, JetBrains + SSH access)
• User cannot set the inactivity timeout more than 24h
• User can set a global user preference for timeout
• https://github.com/gitpod-io/website/pull/3517

Acceptance Criteria (Measurement)

• What values do users set timeouts to? Do they need 24 hours? (e.g. understand use cases for timeouts)
• Are timeouts respected? e.g. users setting X timeout on a long running workspace that is then closed.

In scope

• gp timeout set allows >24 hour timeout (and < 1s) #16085
• [jetbrains-plugin] Update Workspace Timeout Logic #16107
• [gitpod-cli] Flexible Workspace Timeout - <n>days is not working #15945
• Update the VS Code timeout extend behaviour #16157
• Introduce global user timeout default #16200

Out of scope

• https://github.com/gitpod-io/website/pull/3341
• Move the "close timeout" (IDE + editor timeout) to a user preference. #16089
• User can disable the editor inactivity timeout on a per-user basis
• Deprecate gp timeout extend and review timeout defaults #16083
• Unify timeouts for free + paid users (30m vs 60m timeout) #16609
• vscode-desktop extension sometime send heartbeat even computer is in sleep mode #15304
• Review + see the current timeout for a workspace
• Admin / Global default or organisational policy (e.g. not per user)
• Scheduling timeouts
• API's for timeout

Related issues

• Timeout - decrease timeout to less than 30 min. #16565
• Epic: Admin control over workspace timeouts #16090
• Add workspace session time to gp info #16146
• Epic: Full Workspace Backup #7719 + Epic: Persisted Terminal History #9019
• Simplify SSH host - for memorising, constructing from URL, and pasting into SSH clients #11355
• Show remaining timeout in editor + dashboard #11700
• Workspace "about to" timeout prompt  #11263
• Improve Gitpod timeouts for multiple clients (revise the 5 minute editor connection timeout) #10373
• Add a friendly explanation to Timed Out workspaces #7685
• Increase timeouts for shared running workspaces #6300
• Epic: Restart workspaces directly from VS Code Desktop #9221
• https://github.com/gitpod-io/website/issues/2144
• Alert/notification for workspace timeout #13498

Depends on:

• Epic: Usage-Based Pricing #9036

Potential fixes

Solutions for flexible timeout options:

• Setting a default per-user - e.g. allowing users to change the default workspace timeout
• Setting a schedule - e.g. allowing users to configure a schedule where workspaces do not timeout. [1]
• Extending timeouts arbitrarily - e.g. a command in workspace (similar to 3h boost)
• Global default - e.g. Self-Hosted installs able to change the global default (current default is 30min).
• API for timeout - For custom integrations, such as educational products that use Gitpod + want workspaces to timeout for cost reasons, but want to sleep / wake them programatically.

Original description

Summary

Allow users to change the default workspace timeout and extend timeouts arbitrarily. Self-Hosted installs should be able to change the global default (usually 30min).

Context

The automatic timeouts are a convenience feature, that should relieve users from any anxiety about leaving workspaces running forever and therefore creating unnecessary cost.
Currently, it is fixed to 30min resp. 60min (+ 3h boost) for unlimited users.
Once usage-based pricing exists we can allow users to freely choose their timeouts.
We should do this on two levels:

• setting a default per user
• manual command in workspace (similar to 3h boost)

Value

Depending on behaviour patterns and use cases, a different timeout might make sense.

Acceptance Criteria

The new feature (user setting and workspace action) needs to be shipped to SaaS and Self-Hosted release.
The change has been communiticated.

Measurement

The new feature is used by active users. Send events on use.

Growth Area

expansion

Persona(s)

Active users

[corneliusludmann]

See also:

• [installer] Allow to set default workspace timeout #8576.

[corneliusludmann]

Since #8576 is merged, we can set the regular workspace timeout and the extended workspace timeout (when the user clicked the “boost” button) per installation (via installer).

What's still missing is that users are able to set their custom workspace timeouts.

[loujaybee]

https://github.com/gitpod-io/customers/issues/57

[atduarte]

"Tab close timeout" is also an issue at times: #9036 (comment)

[loujaybee]

Whilst there certainly are use cases where longer timeouts are mandatory (e.g truly long running tasks) there are many cases where improving UX to better recover from timeouts etc could also tackle a lot of issues where users are requesting longer timeouts. Wanted to link some related issues to improving timeout UX.

Related issues:

• Workspace "about to" timeout prompt  #11263
• Improve Gitpod timeouts for multiple clients (revise the 5 minute editor connection timeout) #10373
• Add a friendly explanation to Timed Out workspaces #7685
• Epic: Restart workspaces directly from VS Code Desktop #9221
• Show remaining timeout in editor + dashboard #11700
• https://github.com/gitpod-io/website/issues/2144