Outcome
By the end of this lesson, you will be able to trace an event through its lifecycle states, execute rollback (cancel) at the right time, and recover from partial failures.
| Prerequisites | M2.9.L1 · M2.9.L2 |
| Time | 9 minutes |
1. Concept
Event lifecycle has clear states with defined transitions:
draft → scheduling → scheduled → scaling_up → active → scaling_down → completed ↓ cancelled / failedEach state has specific behavior. After scheduling, the transitions run on the clock: a lifecycle worker checks every minute and moves each event on by wall-clock time, not by watching capacity.
State descriptions
draft Event defined but not committed for execution Customer can edit freely
scheduling Cloud-native scheduled actions being created Brief state (~seconds)
scheduled Cloud-native actions in place Event will fire on schedule Pre-event state; can still cancel cleanly
scaling_up Pre-scale window opened: event start minus pre_scale_minutes (default 30) Lasts until event start
active From event start; traffic served Main event duration Can monitor live; can cancel mid-event
scaling_down From event end; capacity scaling back Lasts post_event_minutes (default 60)
completed Event end plus post_event_minutes passed Cleanup restores the baseline Audit log available
cancelled Event aborted before completion Can happen from draft through scaling_down Triggers cleanup
failed A cloud action or restore failed Can happen from scheduling through scaling_down, or after a failed restore on a finished event Can be sent back to draft or re-scheduledOne state at any time.
Cloud-native scheduled actions
Instead of polling, ZopNight uses each cloud’s native scheduled-action mechanism:
AWS ASG PutScheduledUpdateGroupActionAWS ECS Application Auto Scaling PutScheduledActionAzure Autoscale Settings with FixedDate profileGCP scalingSchedulesThese cloud-side actions fire at the configured datetime, no polling required. ZopNight just verifies they’re set correctly.
WHY CLOUD-NATIVE: More reliable (cloud guarantees execution at scheduled time) No ZopNight downtime risk Lower latency to fire Cloud-provider scheduled action semantics well-tested
ZOPNIGHT'S ROLE: Create the scheduled actions Monitor execution Verify outcomes Coordinate across multiple targets Handle rollbackThe cloud handles the trigger; ZopNight handles the orchestration.
Rollback design: byte-accurate restoration
WHEN THE ORIGINALS ARE SAVED: originalMin, originalMax: from the policy when you create or edit the event originalDesired: recorded when you schedule, before any scale-up
ON EVENT START: Cloud actions scale UP to event capacity Pre-warm complete
ON EVENT END: Cloud actions scale DOWN to originalMin, originalMax Original state byte-accurately restored
ROLLBACK IS PROVIDER-AWARE: AWS ASG: sweep cleans up all "zopnight-event-*" scheduled actions Prevents leaks of stale scheduled actions
Azure VMSS: reverts the FixedDate profile Cleans up the temporary profile entries
GCP: cancellation handles map-key deletion PATCH leaves stale schedules; full Update with ForceSendFields fixes this
Provider-specific quirks handledThe byte-accurate rollback is what makes Event Readiness safe.
Concurrent event handling
SCENARIO: Event 1 active: 30 instances Event 2 requested overlapping with Event 1
ZOPNIGHT ALLOWS the overlap: Each write carries the max of the baseline and every event live at that moment GCP takes the max of open schedules natively One event's revert does not shrink a fleet another event still needs
WHAT IS REJECTED: Two Schedule calls racing on the SAME event (only one wins; the other is told to retry)Overlaps compose. Still plan them deliberately, because the combined capacity is the larger of the two, not the sum.
Cancel before, during, or after
BEFORE EVENT START (state: scheduled): CANCEL: removes the cloud-side scheduled action No infrastructure mutation occurred No cost incurred yet Clean abort
DURING EVENT (state: active): CANCEL: triggers immediate scale-back to original capacity ZopNight calls cloud APIs to restore Cost stops at original capacity Recovery from "wait this isn't going as planned"
AFTER EVENT END (state: completed): CANCEL: not available; event is historical Audit log preserved No infrastructure changes possibleThe cancel button is available in any pre-completed state. Different effect depending on state.
Lifecycle event log
Every state transition is logged:
EVENT LOG: black-friday-2026─────────────────────────────────────────────────────────T+0d draft created by user@teamT+5 min scheduling triggeredT+10 min scheduled: cloud actions registeredT+25 days-30m scaling_up started (pre-scale window opens)T+25 days active (event start)T+26 days scaling_down started (event end)T+26 days+60m completed (post-event window ends)Audit trail spans the full lifecycle.
Failure handling
SCHEDULING PHASE FAILURE: Cloud API call fails during scheduling State: failed Customer action: retry via UI; or cancel + recreate No partial state in cloud
SCALING_UP PHASE FAILURE: Not all targets reach event capacity (partial scale-up) State: active (with reduced capacity) Customer notified Customer action: cancel or proceed with reduced capacity
SCALING_DOWN PHASE FAILURE: Not all targets return to baseline State: failed Customer action: retry via UI; or manually verify cloud state
GENERAL FAILURE recovery: Idempotent operations Saved state preserved Audit log captures the failure point Customer can resume from where it stoppedFailures are visible and recoverable. No silent state corruption.
Notification at each state transition
NOTIFICATIONS FIRE on state transitions:
draft → scheduling: "Event scheduling in progress" scheduling → scheduled: "Event scheduled successfully for Nov 28" scheduled → scaling_up: "Pre-scale window open; pre-warming" scaling_up → active: "Event live" active → scaling_down: "Event ending; scaling back" scaling_down → completed: "Event complete; baseline restored" any → cancelled: "Event cancelled" any → failed: "Event failed to scale; check the activity log"
Customer aware of progressionOn-call team can monitorStakeholders can plan around eventThe visibility into state is part of the trust model.
2. Demo
A complete event lifecycle:
DAY -30 draft state Event configured for Nov 28 00:00 - 23:59 UTC Capacity multiplier: 3x Customer reviews configuration
DAY -29 Customer clicks Approve State: scheduling ZopNight creates cloud-native scheduled actions: PutScheduledUpdateGroupAction for ASGs ECS PutScheduledAction for services State transition: scheduled Notification: "Event scheduled successfully"
Cloud-side: scheduled actions now registered Will fire on Nov 28 00:00 UTC
DAY -1 (Nov 27 23:30 UTC, 30 min pre-scale) Cloud-native scale-up action fires Lifecycle worker moves the state by the clock State transition: scaling_up Notification: "Pre-scale window open; pre-warming"
DAY 0 (Nov 28 00:00 UTC) Event start State: active Notification: "Event live"
DAY 0 +24 hr Event end State transition: scaling_down Notification: "Event ending; scaling back"
DAY 0 +24 hr +60 min (post-event window) State: completed Cleanup restores the baseline Notification: "Event complete, baseline restored" Cleanup verified: no stale scheduled actions
24-HOUR EVENT cleanly traced: 6 state transitions A notification on every transition Full audit log Zero manual intervention24-hour event, full lifecycle traced.
3. Hands-on (5 min)
Trace through an event’s lifecycle:
□ STEP 1: Open Event Readiness; pick an event Event: __________ Current state: __________
□ STEP 2: Check audit log draft → scheduling: ___ minutes scheduling → scheduled: ___ minutes scheduled → scaling_up: ___ (at event start) scaling_up → active: ___ minutes active → scaling_down: ___ (at event end) scaling_down → completed: ___ minutes
□ STEP 3: Identify state-specific actions taken scheduling: cloud actions created scaling_up: capacity ramping active: traffic served scaling_down: capacity restoring
□ STEP 4: Verify rollback Final capacity matches original? No stale scheduled actions? Audit complete?
□ STEP 5: Cancel option in current state Available? □ Yes □ No What would happen if cancelled?A 10-minute trace builds confidence in the lifecycle.
Do it through MCP. The same task you just did in the console, asked in one sentence.
BEFORE A ZopNight account with one cloud connected. Something that scales: an Auto Scaling Group, an ECS service, a Managed Instance Group or a VM Scale Set.ASK "Build an event readiness plan for Friday's launch, then tell me what it would cost."CHECK the estimate before you schedule it. The plan is cheap to change now and expensive to change on the night.Tools behind it: create_event_readiness (write, tier 2, reversible), preview_event_readiness (write, tier 1, metadata only), get_event_cost_estimate (read, Cost). Connection details are in the MCP integration docs.
4. Knowledge check
Q1
An event in scheduled state: cancel removes:
A. The whole event, including its history
B. The event entirely from history
C. The event’s cost estimate only
D. The cloud-native scheduled action
Show answer
Correct: D. Cancelling before execution removes the cloud-side trigger, so the scaling never fires and the infrastructure is unchanged.
Q2
Concurrent events on the same target:
A. Allowed: overlapping events compose
B. Both run with priority
C. Rejected: one event per target at a time
D. Queued, and run one after the other
Show answer
Correct: A. Overlaps are allowed. Each write carries the max of the baseline and every live event, so one event’s revert does not shrink capacity another still needs.
Q3
Event end fires; cloud-side action triggers scale-down. ZopNight’s responsibility:
A. Move the state by the clock (scaling_down at event end, completed after the post-event window) and run the cleanup restore
B. Initiate the scale-down
C. Deletes the event record entirely once the scale-down has completed successfully at the cloud provider end itself
D. AWS handles it
Show answer
Correct: A. Cloud actions drive the scaling; a 1-minute lifecycle worker advances the state by wall-clock time and pushes a cleanup restore on completion.
5. Apply
Event Readiness UI shows the current state and audit trail for each event.
For your team: trace at least one event end-to-end before relying on it for production.