Problem

When a workspace autostops, the audit log shows build_reason: autostop but provides no context about why the autostop was triggered. This makes troubleshooting difficult, especially in scenarios where:

1. Template settings were recently changed (see Warn template admins that autostop/activity_bump changes don't affect running workspaces #21688)
2. Users claim they were "actively using" the workspace
3. Admins need to understand if activity detection failed or deadline was never extended

Current Audit Log Entry

{
  "build_reason": "autostop",
  "workspace_name": "my-workspace",
  "workspace_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

This tells us what happened but not why.

Proposed Solution

Enhance the autostop audit log to include:

Enhanced Audit Log Entry

{
  "build_reason": "autostop",
  "workspace_name": "my-workspace",
  "workspace_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "autostop_context": {
    "deadline": "2025-01-15T14:51:00Z",
    "deadline_set_at": "2025-01-15T06:51:00Z",
    "last_activity_at": "2025-01-15T14:49:00Z",
    "last_deadline_bump_at": null,
    "activity_bump_ms": 0,
    "ttl_ms": 0
  }
}

With this context, an admin can immediately see: "Deadline was set 8 hours ago, activity_bump was 0, and the deadline was never bumped (last_deadline_bump_at: null). Even though there was activity 2 minutes before the stop, the deadline couldn't be extended."

Related Issues

• Warn template admins that autostop/activity_bump changes don't affect running workspaces #21688 - Warn template admins that autostop/activity_bump changes don't affect running workspaces
• Explain why workspace is kept alive #17320 - Explain why workspace is kept alive (inverse problem - why workspace didn't stop)

Impact

• Support: Dramatically reduces time to diagnose autostop complaints
• Self-service: Admins can understand autostop behavior without contacting support
• Auditability: Better compliance and debugging for enterprise customers

Created on behalf of @bjornrobertsson