You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many users have reported frustration with workspaces not automatically shutting down as expected with their autostop configuration. The TTL of these workspaces is extended by our activity bump feature, which postpones the shutdown when a user is "active" in a workspace.
However, the definition of activity can be a bit convoluted, and consequently, the activity bump behavior is unpredictable. Administrators want to diagnose exactly why a workspace is being kept alive when seemingly no connections are active. Then, the administrator can hunt down the connection and close it or roll out a permanent solution.
A solution should help administrators understand:
When the last time a workspace's TTL was bumped
The type of connection that incremented it
The source of that connection (some client ID possibly?)
Note
We implemented this previously with a connected pill in the workspace dashboard. However, because viewing a workspace in the dashboard counted as activity, this was practically always active. Additionally, it did not sufficiently inform users on where the connection was coming from.
A proposal
A user suggested logging the events or the last event that bumped activity on the workspace page. Something simple like a schedule tooltip that shows:
Activity detected from <source> <time> ago.
Activity detected from webterminal 15 minutes ago.
Activity detected from SSH 46 minutes ago.
The text was updated successfully, but these errors were encountered:
Problem Statement
Many users have reported frustration with workspaces not automatically shutting down as expected with their autostop configuration. The TTL of these workspaces is extended by our activity bump feature, which postpones the shutdown when a user is "active" in a workspace.
However, the definition of activity can be a bit convoluted, and consequently, the activity bump behavior is unpredictable. Administrators want to diagnose exactly why a workspace is being kept alive when seemingly no connections are active. Then, the administrator can hunt down the connection and close it or roll out a permanent solution.
A solution should help administrators understand:
Note
We implemented this previously with a
connected
pill in the workspace dashboard. However, because viewing a workspace in the dashboard counted as activity, this was practically always active. Additionally, it did not sufficiently inform users on where the connection was coming from.A proposal
A user suggested logging the events or the last event that bumped activity on the workspace page. Something simple like a schedule tooltip that shows:
The text was updated successfully, but these errors were encountered: