Before
Team members likely had to remember to start the Test environment at the beginning of the workday and stop it afterward, then check each instance manually to confirm the requested state. Any failed transition also had to be identified and communicated to the team separately.
How it works
- Receive the trigger, evaluate the weekday and time against the configured Monday-to-Friday, 08:00-to-20:00 working period, and choose whether the environment should be running or stopped.
- Find the EC2 instances tagged as Test, apply the selected start or stop action to each instance, wait, and verify the resulting state.
- Compile successful and unsuccessful transitions into a status message and deliver it to the team Slack channel.
Workflow details
- Trigger and timing: The workflow begins when an incoming email or webhook event is received. It is designed to support the twice-daily operating pattern described in the playbook, with the current date evaluated against Monday-to-Friday working days and the configured 08:00 to 20:00 working window.
- Working-period decision: The automation determines whether the current time falls within a working day and working hours. During working time it follows the start path; outside working time it follows the stop path, without requiring a person to make the decision.
- Instance discovery: The workflow searches the configured EC2 environment for instances tagged with the Test environment and builds the set of instance identifiers to process. Each identified instance is handled individually.
- Lifecycle action and validation: During working hours, each targeted instance is started and then checked after a waiting period to identify instances that remain down. Outside working hours, each targeted instance is stopped and checked afterward to identify instances that remain running. Failed starts and stops are collected into separate status lists.
- Team reporting: The workflow formats a status message with the current time, the affected environment, the number of unsuccessful transitions, and the relevant instance list. It posts that report to a Slack channel so the team can see whether the environment was started or stopped successfully and investigate exceptions.
What changed
The start-or-stop decision, instance lookup, state verification, failure collection, and team notification now happen as one automated flow. Human involvement shifts from performing the routine transition and follow-up checks to reviewing the Slack report when an instance fails to change state.
Work removed
Remembering the start and stop windows, locating the Test environment instances, issuing start or stop actions one by one, waiting for completion, checking each instance's final state, counting failures, and manually notifying the team.
Expected outcome
At least one recurring manual start/stop and verification cycle is removed per execution, with unsuccessful transitions surfaced in Slack; exact time savings depend on the number of targeted instances.
