Ordering only bites on the way up. Stopping three hundred instances in whatever sequence the API returns them is mostly harmless, because the work is going away anyway. The morning start is where the graph asserts itself: the app process comes up, finds nothing listening on the database, and exits, and a crash loop is that same process being restarted faster than its dependency becomes ready [3]. The post's prescription is storage, then compute, then application, with delays between tiers [4]. Delays are the weak part of that. A sleep is an open-loop guess about boot time; the primitive you want is a readiness check against the tier below, with a sleep as the fallback for when the check itself is unavailable. The lower tier can easily miss the window you guessed.
Discovery gives you a set of IDs; sequencing needs edges between them. The snippet shows the gap plainly. It filters on tag:env alone, with no instance-state filter and no pagination handling, then hands one flat list to stop_instances [2][16]. That shape never records what it intended to stop, so the silent-failure mode stays undetectable from inside the script [8].
The fifteen-instances figure is arithmetic on an assumption rather than a measurement; the post offers 5% as an illustration and does not report a rate it observed [17]. For the number to transfer you would need roughly three hundred tagged instances, a per-night stop failure rate near 5%, and no post-run check. The first two you cannot know without the third. Persist the intended ID set before the stop call, describe the instances again ten minutes later, and diff. The size of that diff is your number, and state-transition failures are exactly the ones that keep billing while still looking scheduled [9].
RDS earns its own line in the design. It stops through a different call, and a stopped instance restarts itself after seven days [10]. Held off for a year, that is 365 / 7, about 52 unrequested restarts per instance, each one billing until something notices and stops it again [13]. An evening schedule catches those the same night. A weekend-only schedule does not.
Worth holding in mind about the source: it closes by recommending ZopNight, a product built for this problem across resource types and clouds [12]. The four failure modes still hold up on their own merits, and the requirements list also reads like a product spec, with tag-driven discovery, timezone-aware schedules per environment, time-bounded overrides, and reconciliation with alerting as features being sold as well as features you need [14]. The list survives its provenance because each item maps to a failure you can reproduce. The single UTC cron is the easiest to reproduce: one global 20:00 either kills an environment in the middle of someone's afternoon or leaves it up all night [5].
The observation I would trust most is about human behaviour, not APIs. The post says the override problem breaks first for most teams, usually one badly timed shutdown during a release [15]. A schedule switched off "just for now" reliably costs you the savings it was supposed to deliver [6].
