Scheduling AWS Step Functions State Machine
states:StopExecutionCan ZopNight schedule AWS Step Functions State Machine?
Step Functions has no off state, so the schedule enforces quiet hours by calling states:StopExecution on in-flight executions during the window. A stopped execution is terminal: nothing resumes at start, and reruns begin from step 1. The halt works on Standard workflows only, since Express executions cannot be stopped.
How the stop works
| Field | Value |
|---|---|
| Behaviour | in-flight executions are halted via states:StopExecution during scheduled off-hours windows. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
There is no off switch on a state machine
A state machine is a definition, not a running resource. It bills nothing while idle and
cannot be stopped, paused or deallocated. What a schedule can control is executions. During the
off-hours window, in-flight executions are halted via states:StopExecution, which is a
fundamentally different contract from every stop-and-resume schedule on this directory.
Halted means finished, permanently
A stopped execution transitions to a terminal state and will never continue. The morning start does not resume anything; if the work still matters, something must start a new execution, and that new execution begins at the first state. Workflows living under this schedule need to be built for it: idempotent steps, progress checkpointed outside the execution (DynamoDB, S3, a database), and an input shape that lets a rerun skip completed work.
Standard only
states:StopExecution applies to Standard workflows. Express executions cannot be stopped from
outside; they run to completion or time out within their 5-minute ceiling. An Express-heavy
system simply has nothing for this schedule to grab, which is fine: five minutes of overrun
past the window boundary rarely matters.
The saving lives downstream
Standard workflows bill per state transition, and a halted execution stops accruing them, but transition costs are rarely the point. The real money is in what the states do: the Glue jobs, the SageMaker training, the fleets of Lambda invocations, the polled APIs. Halting the orchestrator stops it driving those resources through the night. One caution: a job already started by a state may continue on its own after the execution stops, so verify whether the integration cancels children or abandons them, per service.
Use the window as a change freeze
Because the halt is enforced rather than advisory, the off-hours window doubles as a deployment-safe period: no execution can be mid-flight at 3am while a schema migration runs. Teams that fight long-running workflows during maintenance windows get that guarantee for free.