agent verified the shutdown worked by checking the console - the stop call hit a permission error it swallowed and...

TL;DR

The API response is the truth; the console page is a rumor. Capture the stop call's response, confirm the instance actually entered the stopping state with describe-instances, and let any error fail loudly. An agent that swallows a permission error will report victory while the meter keeps running.

agent verified the shutdown worked by checking the console  -  the stop call hit a permission error it swallowed and the instances kept running

Steps

1. Reproduce the call and watch the response instead of the console:

aws ec2 stop-instances --instance-ids [instance-id]

Expected: either a StoppingInstances block with the state moving to stopping, or a ClientError naming the missing permission.

1. Confirm with a second read:

aws ec2 describe-instances --instance-ids [instance-id] --query 'Reservations[].Instances[].State.Name'

Expected: "stopping" or "stopped". Anything else means the action did not land.

1. Find the swallowed error in the agent's code: look for catch-all handlers around the stop call that log and continue, and for "verify" steps that reload a cached page instead of re-querying.

Expected: you find the exact line where the error died silently.

1. Change the pattern: no error is caught without re-raising or halting the run, and verification always re-reads state from the API.

Expected: the next permission failure pages someone instead of printing "shutdown complete".

Use this when

• instances still run after automated shutdowns
• the agent's "verified" claims do not match reality
• errors vanish into logs nobody reads

Not for this skill when

• the stop call genuinely succeeded (check state first)
• the instances are being restarted by an autoscaler (that is a different fight)
• the error is throttling rather than permissions (add backoff instead)

Variant phrasings

• "stop-instances permission error ignored"
• "agent said instances stopped but they are running"
• "automation swallowed AWS error"

Why it happens

SDK calls surface failures as exceptions or error fields, and hurried automation wraps them in catch-all handlers that log at debug and move on. The "verification" step then checks a stale source (a console page, a cached inventory) instead of live state, so the lie survives all the way to the report.

Edge cases

• DryRun is your friend: run stop-instances with --dry-run first. A DryRunOperation success means permissions are fine.
• Some instances cannot stop (instance-store root volumes, or members of an autoscaling group). The API tells you, if you listen.
• In cross-account setups the error may be a trust-policy denial, which looks identical to a missing permission. Check both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PWVj-qbf25Q9j-SenjynOg