@ammario an enterprise prospect today with JupyterLab as a use case reported that a scheduled stop will not work for them, but they want an activity-based stop.

The problem they want to solve is their existing cloud JupyterLab solution just keeps workspaces running if a Python kernel is active, and runs up a big cloud bill.

JupyterLab introduces a couple of areas worth considering.

1. It is a web-based app, so no config-ssh settings help them
2. JupyterLab is a coder_app so not how we detect if one of these are open (maybe like how we did in v1)

I couldn't find where I originally suggested this, but I believe we should expose a mapping from a user event/activity to a grace period. When an event with a positive grace period happens, we reset the timer to that specific grace period value. If it's negative, we don't reset the timer. If it's zero, we reset to a default value that comes from elsewhere, either the template or some kind of policy rule.

What we'd have out of the box is a default say one hour grace period with a few minor events overridden to not count.

Surfacing @Mainstay-Noah-Huppert's comment in #3191

That could be good. I do like the schedule so that my workspace doesn't shut down during lunch or during a meeting heavy day. Mainly because there are some development tasks (👀 webpack) that take a few minutes to start up with a big app. So having the workspace up and the tasks already running saves time. Additionally having the scheduled start at 9:00 AM is nice because I know that by the time I start dev work after standup all those tasks will be running and good to go.

For my particular use case I think being able to configure only having keep alive functionality and not inacitvity shutdown would be nice.

Gonna unassign this for now. The RFC has been finished and a proposed behavior is in #3529. We still need to make a few decisions about whether we want to support a feature like this prior to #3597 which can give us better data about user activity.