Auto Suspension

Running workloads in a sandbox consume CPU and memory resources. Developer usage patterns are typically spiky — active during working hours and idle the rest of the time. Crafting automatically suspends idle sandboxes to reduce resource consumption and cost.

At the same time, sandboxes running non-interactive, long-running tasks should not be interrupted. Crafting provides flexible configuration options to handle both cases.

Auto Suspension Period

The auto suspension period is configured at the org level. When a sandbox is detected as idle and remains idle beyond this duration, it becomes eligible for suspension.

Pinned Sandboxes

A sandbox can be Pinned to prevent automatic suspension. This is useful for sandboxes running long-running tasks without human interaction.

To avoid abuse, org admins can configure a maximum duration for pinned sandboxes. A sandbox is automatically Unpinned after this duration.

Org admin options when pinning:

Bypass the maximum pinned duration (pin forever).
Specify a custom pinned duration.
Limit the maximum number of pinned sandboxes across the org.

Note: A pinned sandbox may still be affected by auto scale-in of the underlying compute resources. When that happens, workloads of a pinned sandbox will be rescheduled (moved and restarted) to release underutilized machines.

Mission Critical

For urgent situations where high availability is required, a developer can request Mission Critical state for a sandbox with a specified duration. The state ends automatically after that period unless renewed.

Mission Critical guarantees:

The sandbox will not be suspended.
The sandbox will not be rescheduled or moved when auto scale-in occurs — the underlying compute resource is maintained for that sandbox.

Idle Detection

Crafting has built-in idle detection that considers a sandbox active when any of the following are present:

Active SSH connections
Active remote exec connections
Active port-forwarding connections
Active remote desktop connections
Open Web Terminal or Web IDE sessions
Open JetBrains IDE sessions
Active connections from endpoints
Running AI agents

Custom Activity Probes

Custom activity probes can be defined to introduce additional idle detection logic:

workspaces:
- name: example
  probes:
    activity:
    - name: custom1
      command: /etc/scripts/is-activity-going.sh

If an activity probe returns a positive (non-zero exit code or specific output indicating activity), the workload is considered active.

Configuring Built-in Probes

Specific built-in probes can be disabled:

workspaces:
- name: example
  probes:
    activity_detection:
      disable_builtin_probes:
      - ENDPOINT
      - AGENT

Or only specific probes can be enabled by first disabling all built-in probes:

workspaces:
- name: example
  probes:
    activity_detection:
      disable_builtin_probes:
      - ANY    # Disable all built-in probes
      enable_builtin_probes:
      - PORT_FORWARD
      - EXEC

Note: The probes definition applies to both workspaces and container workloads.

Enhanced Auto Suspension

Standard idle detection relies on the existence of connections and sessions. However, many developers leave their computers on with live connections to Crafting while not actively working, which defeats basic idle detection.

Enhanced Auto Suspension applies statistical models to the traffic from existing connections and sessions to determine whether real activity is happening. If no real activity is detected, the workload is considered idle and eligible for suspension — even with open connections.

Since the accuracy of the model is not 100%, it may occasionally disrupt sandboxes during brief pauses in working hours. The recommended approach is to enable Enhanced Auto Suspension only during specific time windows (e.g. after working hours) with a shorter auto suspension period.

These settings are configured at the org level in Team / Settings in the Web Console.