Step Functions state machines with no executions, and why they carry no saving

You pay for steps taken, not machines defined

AWS Step Functions pricing charges Standard Workflows for the number of state transitions, counted each time a step of a workflow executes, including retries; the free tier covers 4,000 transitions a month. Express Workflows are charged by the number of requests and their duration. Neither model has a monthly fee for a state machine that exists but does not run.

A forgotten state machine is therefore free. What it can still cost you is attention: an IAM role with broad permissions attached to it, EventBridge rules that would start it, and a definition that nobody remembers owning.

Finding state machines that have not started

The ExecutionsStarted metric lives in the AWS/States namespace. AWS notes in its Step Functions metrics guide that it emits two ExecutionsStarted datapoints per execution, so use Sum, not SampleCount, when counting. The execution list is often the quicker check:

aws stepfunctions list-state-machines --query 'stateMachines[].stateMachineArn' --output text

aws stepfunctions list-executions \
  --state-machine-arn arn:aws:states:us-east-1:111122223333:stateMachine:my-flow \
  --max-items 1 --query 'executions[].[name,startDate,status]'

An empty result, or a newest startDate months in the past, marks a candidate for review.

A check that is deliberately silent

This check is registered and ZopNight collects ExecutionsStarted for state machines, but it returns no recommendation for any state machine. ZopNight raises cost findings only when there is a concrete dollar figure behind them. With billing tied entirely to transitions and requests, a machine with no executions has a cost of zero, and no amount of better detection would turn that into a saving. An older version relied on a tag that was never populated; that path has been removed rather than repaired.

What this means for your recommendations list

You will not see Step Functions entries from this check. That is expected, not a data gap. Busy state machines that are expensive because they run too many transitions are a design question, not an idle one.

Nothing to save, some things to tidy

There is no savings figure. The value of a cleanup is security and clarity: fewer execution roles with standing permissions and fewer triggers that could start forgotten logic.

Removing a state machine you no longer need

1. Look for EventBridge rules, API Gateway integrations or other workflows that start it.
2. Export the definition if you may want it again (aws stepfunctions describe-state-machine).
3. Delete it with aws stepfunctions delete-state-machine --state-machine-arn and the ARN.
4. Review the execution role and delete it if nothing else assumes it.