-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Epic: Admin control over workspace timeouts #16090
Comments
A vote for this from a long-term paid organisation. Our users are already starting to set higher timeouts and increasing our costs on the new plan without us having any control over this. Please implement ASAP! |
Very much needed to control the cost. |
Also the ability to restrict the workspace type at the same time. We only want our users to use the standard class to avoid racking up unnecessary costs. |
@lalitindoria, @davidwindell - thank you for the feedback 🙏 We are actively looking into ways to better provide cost controls into Gitpod. If you (or others) reading this issue are open to discuss those controls in Gitpod, so that we can learn more about your org and setup with Gitpod, I'd love to chat to you: |
@loujaybee I don't have time for a chat, but what I have outlined above is super critical for cost control. We need to be able to limit the class of machine and timeout duration for our users. Those two things are all we need. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This needs to stay open. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
With the introduction of UBP, and the ability for users themselves to update the timeouts of workspaces, this feature request would then allow an admin to control the timeout policies for users within a Gitpod organisation, mainly for cost management purposes: #9038
The text was updated successfully, but these errors were encountered: