Problem
When a template admin changes default_ttl or activity_bump settings, existing running workspaces retain their pre-existing deadlines. This is intentional behavior (per #2229), but it creates a confusing experience:
- Admin disables autostop (
default_ttl=0) expecting workspaces to run indefinitely
- Admin also disables activity bump (
activity_bump=0)
- Existing running workspaces still have their old deadlines
- Since
activity_bump=0, user activity can no longer extend those deadlines
- Workspaces autostop when their old deadline passes, despite the admin believing autostop was disabled
The user appears to be "actively using" the workspace, but activity detection doesn't matter when activity_bump=0.
Why This Happens
Deadlines are stored on the workspace build, not the template. When a build completes, the deadline is calculated from the template settings at that moment:
deadline = build_completed_at + TTL (if TTL > 0)
deadline = zero (if TTL = 0) → means "no autostop"
Changing template settings doesn't retroactively update existing builds. This is documented in the lifecycle executor:
// NOTE: If a workspace build is created with a given TTL and then the user either
// changes or unsets the TTL, the deadline for the workspace build will not
// have changed. This behavior is as expected per #2229.
Proposed Solution
UI
- Add a warning banner in the template schedule settings page when changing
default_ttl, activity_bump, or autostop requirements
- The warning should explain that running workspaces will keep their existing deadlines until restarted
- Optionally show the count of running workspaces that have active deadlines
Documentation
- Swagger/OpenAPI: Add
description annotations to default_ttl_ms and activity_bump_ms fields in UpdateTemplateMeta explaining that changes don't affect running workspaces
- Template scheduling docs: Add a dedicated section on "How deadline changes propagate" with clear examples
CLI
coder templates edit could print an informational message after successful update when TTL/activity_bump settings are changed
Workaround
Currently, users must restart their workspace after template changes to pick up new autostop settings.
Created on behalf of @bjornrobertsson
Problem
When a template admin changes
default_ttloractivity_bumpsettings, existing running workspaces retain their pre-existing deadlines. This is intentional behavior (per #2229), but it creates a confusing experience:default_ttl=0) expecting workspaces to run indefinitelyactivity_bump=0)activity_bump=0, user activity can no longer extend those deadlinesThe user appears to be "actively using" the workspace, but activity detection doesn't matter when
activity_bump=0.Why This Happens
Deadlines are stored on the workspace build, not the template. When a build completes, the deadline is calculated from the template settings at that moment:
Changing template settings doesn't retroactively update existing builds. This is documented in the lifecycle executor:
Proposed Solution
UI
default_ttl,activity_bump, or autostop requirementsDocumentation
descriptionannotations todefault_ttl_msandactivity_bump_msfields inUpdateTemplateMetaexplaining that changes don't affect running workspacesCLI
coder templates editcould print an informational message after successful update when TTL/activity_bump settings are changedWorkaround
Currently, users must restart their workspace after template changes to pick up new autostop settings.
Created on behalf of @bjornrobertsson