Skip to main content

Status

Sandbox Status​

Signadot Sandboxes have an associated status expressed in the status field of a sandbox API response, which is visible from the CLI using the -o yaml flag, for example

# signadot sb get my-sandbox -o yaml | yq .status
local: []
message: All desired workloads are available.
ready: true
reason: AllDesiredWorkloadsReady
scheduledDeleteTime: 2025-01-31T00:42:08Z
testExecutions:
  checks:
    failed: 1
    passed: 2
  phaseCounts:
    - phase: pending
    - phase: in_progress
    - phase: failed
    - count: 3
      phase: succeeded
    - phase: canceled
  trafficDiffs:
    green: 24
    yellow: 7

or

# signadot sb get my-local-sandbox -o yaml | yq.status
local:
  - name: local-location
    tunnel:
      health:
        connected: true
        lastCheckTime: 2025-01-30T23:25:57Z
        lastConnectedTime: 2025-01-30T23:25:57Z
message: All desired workloads are available.
ready: true
reason: AllDesiredWorkloadsReady
scheduledDeleteTime: 2025-01-31T07:20:54Z

or

# signadot sb get my-sandbox -o yaml | yq .status
jobs:
  phaseCounts:
    - count: 1
      phase: queued
    - count: 1
      phase: running
    - phase: failed
    - count: 4
      phase: succeeded
    - phase: canceled
message: All desired workloads are available.
ready: true
reason: AllDesiredWorkloadsReady

Readiness and .ready​

The API status of a sandbox is used throughout our system, and defines when a sandbox is ready.

The .reason and .message fields of a status are qualifiers for the .ready field. They provides an indication of what is missing if the sandbox is not ready and what is present and working that summarises why the sandbox is ready.

Readiness is fundamentally a distributed concept. Upon being observed, it may not be current. However, as is common practice, we do our best to ensure that readiness is monotonically tending toward a ready healthy state once a sandbox is created or updated. Events within the cluster with which the sandbox is associated can also intervene, such as an update to a baseline workload or pod eviction by Kubernetes.

.testExecutions​

The test executions field provides a summary of the latest execution for every Smart Test that is associated with the latest version of the sandbox.

It summarises across all such executions, extracting the following values.

.phaseCounts​

As the field name indicates, this is a count of all the test executions with the associated phase. When the count is absent, that indicates there are no such test executions the indicated phase. For example,

- phase: in_progress
- phase: failed
- count: 3
  phase: succeeded

tells us that there 3 succeeded phase test executions, and no in_progress or failed executions.

.trafficDiffs​

Traffic diffs field indicates a count of the diff operations from test executions which capture and compare requests and responses in the baseline and the sandbox. There are 3 categories: red, yellow, and green. red is a high relevancy diff which is unexpected in the baseline. green is a diff which differs from the baseline in a way we expect because the baseline tends to show similar differences. yellow is somewhere in between.

The following:

trafficDiffs:
  green: 24
  yellow: 7

indicates there are no red diff operations, 24 green and 7 yellow.

More information is available here

.checks​

The .checks field indicates the total number of checks in completed test executions.

checks:
  failed: 1
  passed: 2

checks can either be passed or failed. There is no pending or in_progress state.

More information is available here.

.jobs​

The .jobs field of the sandbox status provides a summary of the phases of all jobs associated with the most recent version of the sandbox in the field .phaseCounts:

jobs:
  phaseCounts:
    - count: 1
      phase: queued
    - count: 1
      phase: running
    - phase: failed
    - count: 4
      phase: succeeded
    - phase: canceled

Like the phaseCounts fields of test executions, each entry is an object with two keys: the phase and the count. When count is absent, it indicates no such jobs have this phase. In the above example, there is 1 queued job, 1 running job and 4 succeeded jobs.

.locals​

The .locals field of the sandbox status gives information about local workloads, such as

tunnel:
  health:
    connected: true
    lastCheckTime: 2025-01-30T23:25:57Z
    lastConnectedTime: 2025-01-30T23:25:57Z

A local workload is healthy if the tunnel will direct traffic to the localPort associated with the local workload. This connectivity is checked periodically and the last time it was successfully connected is indicated (if present) as well as the last time a connectivity check occurred.

More information about locals is available here.

Considerations​

Some fields were introduced in different versions of different components. For example, local: will only be populated if the sandbox is running in an operator which supports local development (>=v0.16.0), scheduledDeleteTime was added on the Signadot SaaS shortly after the CLI version v0.3.3 was released.

If you are consistently missing any of the above information, you may be running an older version of either the operator or the cli.