Skip to content
Dreadnode Dreadnode Dreadnode

Runtime limits

How sandbox runtime ceilings are resolved across platform, organization, and request-level limits.

Sandbox runtime limits have a hard ceiling and a default path:

  1. Platform hard max (SANDBOX_MAX_RUNTIME_SECONDS) caps every org and request.
  2. Platform default (SANDBOX_DEFAULT_RUNTIME_SECONDS) applies when an org has no max.
  3. Organization max (max_sandbox_runtime_seconds) lets a platform admin override one org.
  4. Organization default (default_sandbox_runtime_seconds) lets an org owner choose a lower default.
  5. Requested runtime (requested_runtime_limit_seconds) lets a user request a shorter session.

The configured runtime limit for a sandbox or runtime instance is the minimum effective value across these levels.

For example, a platform can set an 8 hour hard max and a 1 hour default. An org with no max inherits 1 hour, while a platform admin can set another org to 2 hours. Requests above 8 hours are rejected.

Source labels

Section titled “Source labels”

API responses include source-level metadata so clients can explain whether a value is set locally or inherited:

  • l1_platform_max
  • l1_platform_default
  • l2_org_max
  • l3_org_default
  • l4_requested

For sandbox and runtime payloads, look for:

  • requested_runtime_limit_source_level
  • configured_runtime_limit_source_level

For organization payloads, look for:

  • max_sandbox_runtime_source_level
  • default_sandbox_runtime_source_level

Effective fields

Section titled “Effective fields”

Organization responses also include effective values after inheritance:

  • effective_max_sandbox_runtime_seconds
  • effective_default_sandbox_runtime_seconds
  • platform_default_sandbox_runtime_seconds
  • platform_max_sandbox_runtime_seconds

This lets UI and CLI surfaces show a resolved duration without recomputing the hierarchy client-side.