Can Gitpod’s idle timeout affect detached terminal processes?

Answer

Yes. Gitpod’s idle‑timeout shuts down the whole workspace container after a configurable period of inactivity, and that shutdown kills every process inside the container – detached or not. A detached process (started with nohup, setsid, or inside screen/tmux) will run until the container is stopped, but it is not immune to the idle‑timeout event.

Why It Happens

The idle‑timeout is implemented at the container level. When the timer expires, Gitpod sends a SIGTERM to the container’s init process and then removes the container. All child processes are terminated as part of the container’s lifecycle. Because there is no separate “background job manager” in a Gitpod workspace, the timeout does not distinguish between foreground and detached jobs.

How to Verify

1. Open a Gitpod workspace and start a long‑running command in a screen or tmux session:

   tmux new -d -s test
   # Inside the session, run a long process
   sleep 3600 > /tmp/sleep.log &

2. Detach from the session (Ctrl‑A D for screen, Ctrl‑B d for tmux) and close the IDE.
3. Wait until the default 30‑minute idle timeout triggers (or adjust idleTimeout in .gitpod.yml to a shorter value for faster testing).
4. Re‑open the workspace and run ps -ef | grep sleep. The process should no longer be present.

Mitigation Strategies

• Increase the timeout: Add idleTimeout: 60 (in minutes) to .gitpod.yml to give your job more time.
• Use keepAlive: Set keepAlive: true to keep the workspace alive as long as the IDE is open, but note that it does not affect the container after the IDE disconnects.
• Run critical jobs outside the workspace: Spin up a separate VM, cloud instance, or Kubernetes pod that is not subject to Gitpod’s idle policy.
• Persist data: Store outputs in a persistent volume or push them to a remote repository before the timeout triggers.

Missing Diagnostic Detail

Do you run the process inside a screen or tmux session, or do you rely on nohup and backgrounding? This can affect how you manage the process before the container stops, but the final outcome remains the same: the container shutdown will terminate the job.