Bulk-Pausing Every Signal of a Given Type with the Clay CLI

Stop every signal of a specific type from running and spending credits in one pass, using signals list piped into signals pause, against real multi-signal state in this workspace.

What you will build

A type-scoped bulk pause: find every signal of one type regardless of its current status, then pause them all in one pipeline.

clay signals list | jq -r '.data[] | select(.signal.type == "<Type>") | .id'
    ↓
xargs -n1 clay signals pause
    ↓
every matching signal's runStatus becomes "Paused"

AI Prompt

Using the Clay CLI, bulk-pause every signal of a given type.

Requirements:
- `clay signals list` returns every signal in the workspace unpaginated,
  each with `signal.type` and the current `runStatus`.
- `clay signals pause <triggerDefinitionId>` returns the signal with
  runStatus already updated. It's a no-op (not an error) on a signal
  that's already Paused, and it applies whether the target is Active or
  already Paused, so a bulk pause pipeline doesn't need to pre-filter by
  current status, only by type.
- Only Active or Paused signals can be paused. An Errored, Testing,
  Disabled, or Preview signal is refused rather than silently skipped, so
  a bulk xargs pipeline over a mixed set of statuses will show individual
  failures for those, rather than a clean run.
- Tested against a workspace with more than one signal of the same type:
  the pipeline paused every matching signal, not just the first.
- Run the verification step below before finishing.

Prerequisites

• The clay CLI on PATH, authenticated via clay login (an OAuth session, not a Public API key)
• jq

Note: JSON samples below are trimmed to the fields relevant to each step. Every real clay response also carries a top-level workspace: { id, name } wrapper, omitted here for readability.

1. Activate a signal so there's a real state to change

clay signals resume td_0tlqav4Ecpo5M6tsbV9 | jq -r '.runStatus'

Real output:

Active

2. Bulk-pause every signal of that type

clay signals list | jq -r '.data[] | select(.signal.type == "Promotion") | .id' | xargs -n1 clay signals pause | jq -r '.runStatus'

Real output against this workspace, which had two Promotion-type signals, both paused in one pipeline:

Paused
Paused

3. Confirm the real end state

clay signals list | jq -r '.data[] | select(.signal.type == "Promotion") | "\(.id) \(.runStatus)"'

Real output:

td_0tlqav4Ecpo5M6tsbV9 Paused
td_0tl8a9pr6ufj6PPFm6g Paused

Verify the result

Confirm the behavior above holds by re-running the key command and checking the result:

clay signals list | jq -r '.data[] | select(.signal.type == "Promotion") | .id' | xargs -n1 clay signals pause

Expected: every real signal matching the type filter is returned by signals list, and each one is set to runStatus: "Paused" by the pipeline, including signals already Paused, which is accepted as a no-op rather than an error.

How it works

signals pause being idempotent on an already-Paused signal is what allows the xargs pipeline to run without pre-checking each signal's current status. The same command can run repeatedly, or over a set that mixes Active and already-Paused signals, and converges to "everything of this type is Paused" without any individual call failing. A set that also includes Errored, Testing, Disabled, or Preview signals is the exception: the pause command refuses those rather than skipping them silently.

Common issues

Assuming xargs -n1 clay signals pause fails cleanly if any signal can't be paused

xargs continues past individual command failures by default. A signal in an unpauseable status (Errored, Testing, etc.) prints its own error inline, and the pipeline keeps going for the rest. Check the output for embedded errors rather than relying on the overall exit code alone.

Filtering only on runStatus == "Active" before pausing

Filtering by status first can feel safer, since it only touches signals that are currently running. It isn't necessary, though: pausing an already-Paused signal is a real no-op, so filtering only by signal.type (without also filtering by current status) is simpler and produces the same end state.

Next steps

• Reverse the pattern with signals resume to bulk-reactivate a type after a maintenance window.
• Narrow further with a second jq select on input.audiences.segmentIds to bulk-pause only signals watching a specific audience.

verification:
  status: verified
  tested_at: "2026-09-21"
  product_version: "clay CLI 1.2.0"
  command: "clay signals list | jq -r '.data[] | select(.signal.type == \"Promotion\") | .id' | xargs -n1 clay signals pause"
  expected_result: "Every real signal of the given type in the workspace (two, in this run) is set to runStatus Paused by the pipeline, regardless of each one's starting status."