When a Gitpod workspace times out, is there a configurable grace period for process cleanup?

Uncertainty around graceful termination

I am trying to determine whether Gitpod offers a configurable grace period for in-flight processes when an inactivity timeout triggers workspace termination. The goal is to allow long-running tasks—such as test suites or build jobs—to flush state or exit cleanly before the workspace stops, rather than being killed abruptly.

Current documentation covers task-level timeouts in .gitpod.yml and explains that pinning a workspace prevents automatic inactivity stops, but it does not clearly define a universal shutdown grace period for arbitrary user processes. Additionally, Gitpod Classic and Gitpod Flex manage workspace lifecycle differently, so timeout and cancellation semantics may not transfer between the two platforms.

Does Gitpod send a termination signal to user processes before a timed-out workspace enters the stopped state? Is there a configuration option to extend or customize that grace period, and do Classic and Flex behave identically in this regard?