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

[loujaybee]

I'm going to take ownership of this for the time being, and assign to team: IDE.

I'm also going to update from Q3 as this feature is dependent upon:

• Epic: Usage-Based Pricing #9036

Due to the sensitivity / importance of the dependent pricing changes (i.e it's important we get it right) that it doesn't make sense to push for this change to be delivered in Q3.

[SecludedL]

Thank you for the great job on launching the Pay-as-you-go plan in such a short time!

We switched to the new plan on Friday and still had the same timeout issues as before, meaning that when the browser is closed, the timeout is set to 3 minutes (which is a problem, since we're opting for the PaaG plan specifically to pay in order avoid these short timeouts). Ideally, the workspace would continue running either until you stop it or until it hits the extended timeout (3h or more) and it would completely disregard heartbeat signals (such as having an active browser window).

Can you please confirm that you're still looking to remove the browser close timeout at least for PaaG customers?

Thank you!

[andreafalzetti]

Thank you for the great job on launching the Pay-as-you-go plan in such a short time!

We switched to the new plan on Friday and still had the same timeout issues as before, meaning that when the browser is closed, the timeout is set to 3 minutes (which is a problem, since we're opting for the PaaG plan specifically to pay in order avoid these short timeouts). Ideally, the workspace would continue running either until you stop it or until it hits the extended timeout (3h or more) and it would completely disregard heartbeat signals (such as having an active browser window).

Can you please confirm that you're still looking to remove the browser close timeout at least for PaaG customers?

Thank you!

This is something we believe it should be addressed in Q1, please bear with us until we have more details 🙏

[mbrevoort]

Now with PAYG, what's stopping us from offering significantly longer timeouts? 8 hours? 24 hours? 48 hours?

[mbrevoort]

A very simple "skateboard" could be to expand gp timeout extend to accept a time period. For example:

• gp timeout extend 24h
• gp timeout extend 180m

Up to some reasonable limit within the range of 24h - 72h.

[gtsiolis]

We could also make this a preference in user settings with 2-3 fixed options to select from later. Cc @mbrevoort

[rgoldfinger-quizlet]

It would be nice to have the option to extend both the inactivity timeout and the IDE disconnected timeout.

[svenefftinge]

#15815 adds a gp timeout set <duration>command

[loujaybee]

Thanks for updates, Sven ! :) I'm going to suggest we keep open for now, whilst we gather feedback, and consider any further adjustments to make. We might want to make other, more targeted issues or epics, though.

[SecludedL]

@svenefftinge Hello and thank you for releasing the timeout extension command and for allowing us to have timeouts of up to 1-2 days (possibly more). However, it looks like the <5 minute timeout when closing the browser window still applies, so the utility of timeout extensions is pretty limited at the moment (at least in our case). Is there a way for us to have the timeout honored even when all browser tabs are closed?

[svenefftinge]

@SecludedL Yes, that is definitely something we should be able to disable using that command as well.

[SecludedL]

@svenefftinge - thanks for the swift response! Please do let me know if there's something we can do on our own or if there's a specific issue I can follow to test the feature when it's implemented in Gitpod. Have a great weekend!

[svenefftinge]

For now, I fear the only way to avoid the onclose signal is to either not close the editor or disconnect your network before closing.

[mbrevoort]

I agree, the timeout should extend independent of whether an IDE or browser window is connected or not. If I want to extend the timeout for 24 hours then we should let it run for 24 hours regardless. With pay-as-you-go we should be giving more agency to users.

[loujaybee]

Thanks for the feedback @SecludedL, your request is now encapsulated in this issue:

• Move the "close timeout" (IDE + editor timeout) to a user preference. #16089

I've also raised a couple of related issues, so will link those here, also.

• gp timeout set allows >24 hour timeout (and < 1s) #16085
• gp timeout commands have inconsistent output UX #16084
• Deprecate gp timeout extend and review timeout defaults #16083
• Epic: Admin control over workspace timeouts #16090

[loujaybee]

Some other areas we can look to apply timeout control:

• Admin/orgs/team: Give timeout limit and controls to admins to restrict how much control users in an org have over their timeouts. Mostly to manage spend: e.g. Epic: Admin control over workspace timeouts #16090
• User: The ability for a user to set a timeout value as a default for all future workspaces. So the user doesn't have to run the command on each workspace start, or add to their .gitpod.yml
• Project: Ability to set a specific timeout for a project, where there may be a perpetual need to use an extended timeout for that project, such as when doing long-running data tasks, tests, or sharing the environment for preview purposes.

[loujaybee]

As part of this work, we might want to consider aligning the free tier and paid timeout of 30/60 minutes given that a user can now set the inactivity timeout themselves.

[loujaybee]

Regarding the acceptance criteria:

User can set any timeout up to 24 hours from any client (VS Code, JetBrains + SSH access)

I believe this is completed, can we tick off?

[loujaybee]

Release Announcement