Trigger schedules in bulk

Maintenance windows, migrations and performance tests all start the same way: no trigger schedule may fire while the work is in progress. ewx-cli trigger-schedules disables all trigger schedules on a whole project or on selected namespaces, records exactly which ones it switched off, and later switches those, and only those, back on. Trigger schedules that were already disabled are never recorded, so re-enabling restores the environment instead of changing it.

Both commands need editor permission on the trigger resource of every targeted namespace.

Disable

Targets are projects or namespaces, mixed as you like; aliases and display names are accepted.

ewx-cli trigger-schedules disable demo --dry-run                       # see the scope first
ewx-cli trigger-schedules disable demo                                 # every namespace of the project you can see
ewx-cli trigger-schedules disable demo/enrx_org_001 demo/enrx_org_002  # two namespaces

The command lists what it found per namespace and asks for confirmation (-y skips the question). Already disabled trigger schedules are reported but left alone. What was disabled is written to a state file, by default in the CLI cache (~/.cache/ewx-cli/trigger_schedule_state/), and the command prints the matching reenable command when it finishes. --name labels the state file; --state-file chooses its location; --limit caps how many trigger schedules are retrieved per namespace.

The state file is written before the first change and updated after each one, so a run that is interrupted or fails on some namespaces can still be re-enabled completely.

Re-enable

ewx-cli trigger-schedules reenable demo                    # everything the recorded run disabled on the project
ewx-cli trigger-schedules reenable demo/enrx_org_001       # only this namespace
ewx-cli trigger-schedules reenable demo --state-file ~/.cache/ewx-cli/trigger_schedule_state/1754900000.0___demo___.json

Targets are mandatory, so a recorded run can never be applied by accident. Namespaces must be given by ID here, because that is what the state file records. A target that matches nothing in the state file aborts the run and lists what the file covers.

Without --state-file you pick from an overview of recorded runs, the same one ewx-cli trigger-schedules list-states prints:

[0] Abort
[1] Mon Aug 11 09:31:22 2026 | demo | 37 trigger schedule(s) to re-enable
[2] Fri Aug  8 14:02:07 2026 | demo/enrx_org_001 (name: perf_test) | 4 trigger schedule(s) to re-enable
-> Which recorded run must be re-enabled? [0-2]:

A trigger schedule that someone enabled in the meantime is skipped, as is one that no longer exists. Trigger schedules that could not be enabled keep their recorded state, so running reenable again on the same state file retries just those. --keep-state leaves the state file untouched; --dry-run shows the plan.