Skip to content

Commit bbe7dac

Browse files
authored
docs: document definition of workspace activity (coder#16941)
closes: coder#16884 aligns the documentation with what users see when they adjust settings and uses the [notion discussion](https://www.notion.so/coderhq/Definitions-of-Workspace-Usage-Autostop-Dormancy-e7fa8ff782a948c19bbe4ef8315c26cb) as a reference. This PR reflects current behavior from what I can tell. [preview](https://coder.com/docs/@16884-define-activity/user-guides/workspace-scheduling#activity-detection) --------- Co-authored-by: EdwardAngert <17991901+EdwardAngert@users.noreply.github.com>
1 parent f4b6f42 commit bbe7dac

File tree

2 files changed

+37
-19
lines changed

2 files changed

+37
-19
lines changed

docs/admin/templates/managing-templates/schedule.md

+1-2
Original file line numberDiff line numberDiff line change
@@ -14,8 +14,7 @@ Template [admins](../../users/index.md) may define these default values:
1414
stops it.
1515
- [**Autostop requirement**](#autostop-requirement): Enforce mandatory workspace
1616
restarts to apply template updates regardless of user activity.
17-
- **Activity bump**: The duration of inactivity that must pass before a
18-
workspace is automatically stopped.
17+
- **Activity bump**: The duration by which to extend a workspace's deadline when activity is detected (default: 1 hour). The workspace will be considered inactive when no sessions are detected (VSCode, JetBrains, Terminal, or SSH). For details on what counts as activity, see the [user guide on activity detection](../../../user-guides/workspace-scheduling.md#activity-detection).
1918
- **Dormancy**: This allows automatic deletion of unused workspaces to reduce
2019
spend on idle resources.
2120

docs/user-guides/workspace-scheduling.md

+36-17
Original file line numberDiff line numberDiff line change
@@ -37,18 +37,37 @@ days of the week your workspace is allowed to autostart.
3737
Use autostop to stop a workspace after a number of hours. Autostop won't stop a
3838
workspace if you're still using it. It will wait for the user to become inactive
3939
before checking connections again (1 hour by default). Template admins can
40-
modify the inactivity timeout duration with the
41-
[inactivity bump](#inactivity-timeout) template setting. Coder checks for active
42-
connections in the IDE, SSH, Port Forwarding, and coder_app.
40+
modify this duration with the **activity bump** template setting.
4341

4442
![Autostop UI](../images/workspaces/autostop.png)
4543

46-
## Inactivity timeout
44+
## Activity detection
4745

48-
Workspaces will automatically shut down after a period of inactivity. This can
49-
be configured at the template level, but is visible in the autostop description
46+
Workspaces automatically shut down after a period of inactivity. The **activity bump**
47+
duration can be configured at the template level and is visible in the autostop description
5048
for your workspace.
5149

50+
### What counts as workspace activity?
51+
52+
A workspace is considered "active" when Coder detects one or more active sessions with your workspace. Coder specifically tracks these session types:
53+
54+
- **VSCode sessions**: Using code-server or VS Code with a remote extension
55+
- **JetBrains IDE sessions**: Using JetBrains Gateway or remote IDE plugins
56+
- **Terminal sessions**: Using the web terminal (including reconnecting to the web terminal)
57+
- **SSH sessions**: Connecting via `coder ssh` or SSH config integration
58+
59+
Activity is only detected when there is at least one active session. An open session will keep your workspace marked as active and prevent automatic shutdown.
60+
61+
The following actions do **not** count as workspace activity:
62+
63+
- Viewing workspace details in the dashboard
64+
- Viewing or editing workspace settings
65+
- Viewing build logs or audit logs
66+
- Accessing ports through direct URLs without an active session
67+
- Background agent statistics reporting
68+
69+
To avoid unexpected cloud costs, close your connections, this includes IDE windows, SSH sessions, and others, when you finish using your workspace.
70+
5271
## Autostop requirement
5372

5473
> [!NOTE]
@@ -79,13 +98,13 @@ stopped due to the policy at the **start** of the user's quiet hours.
7998

8099
## Scheduling configuration examples
81100

82-
The combination of autostart, autostop, and the inactivity timer create a
101+
The combination of autostart, autostop, and the activity bump create a
83102
powerful system for scheduling your workspace. However, synchronizing all of
84103
them simultaneously can be somewhat challenging, here are a few example
85104
configurations to better understand how they interact.
86105

87106
> [!NOTE]
88-
> The inactivity timer must be configured by your template admin.
107+
> The activity bump must be configured by your template admin.
89108
90109
### Working hours
91110

@@ -95,14 +114,14 @@ a "working schedule" for your workspace. It's pretty intuitive:
95114
If I want to use my workspace from 9 to 5 on weekdays, I would set my autostart
96115
to 9:00 AM every day with an autostop of 9 hours. My workspace will always be
97116
available during these hours, regardless of how long I spend away from my
98-
laptop. If I end up working overtime and log off at 6:00 PM, the inactivity
99-
timer will kick in, postponing the shutdown until 7:00 PM.
117+
laptop. If I end up working overtime and log off at 6:00 PM, the activity bump
118+
will kick in, postponing the shutdown until 7:00 PM.
100119

101-
#### Basing solely on inactivity
120+
#### Basing solely on activity detection
102121

103122
If you'd like to ignore the TTL from autostop and have your workspace solely
104-
function on inactivity, you can **set your autostop equal to inactivity
105-
timeout**.
123+
function on activity detection, you can set your autostop equal to activity
124+
bump duration.
106125

107126
Let's say that both are set to 5 hours. When either your workspace autostarts or
108127
you sign in, you will have confidence that the only condition for shutdown is 5
@@ -114,10 +133,10 @@ hours of inactivity.
114133
> Dormancy is an Enterprise and Premium feature.
115134
> [Learn more](https://coder.com/pricing#compare-plans).
116135
117-
Dormancy automatically deletes workspaces which remain unused for long
118-
durations. Template admins configure an inactivity period after which your
119-
workspaces will gain a `dormant` badge. A separate period determines how long
120-
workspaces will remain in the dormant state before automatic deletion.
136+
Dormancy automatically deletes workspaces that remain unused for long
137+
durations. Template admins configure a dormancy threshold that determines how long
138+
a workspace can be inactive before it is marked as `dormant`. A separate setting
139+
determines how long workspaces will remain in the dormant state before automatic deletion.
121140

122141
Licensed admins may also configure failure cleanup, which will automatically
123142
delete workspaces that remain in a `failed` state for too long.

0 commit comments

Comments
 (0)