Event readiness

Event readiness is for the planned spike. Black Friday, a product launch, a load-test window. You define the event, ZopNight pre-scales the targets ahead of it, runs the event at the scaled capacity, and restores the original configuration afterwards. The capacity math is real; it reads your autoscaler policy posture and recent activity, not just a guess at headroom.

Event Readiness; each planned event with its traffic multiplier, targets, lead time, and lifecycle state.

When to use it

Situation	Good fit?
Marketing launch with predicted traffic spike	Yes
Black Friday or seasonal sale	Yes
Scheduled load test	Yes
Datastore failover drill	Monitor-only (ZopNight does not modify customer DBs)
Unplanned spike happening right now	No; use the autoscaler, not event readiness
Permanent capacity increase	No; change the autoscaler policy directly

What ZopNight can scale

Infrastructure-only. Database scaling stays with your team.

Target	Provider	What ZopNight does
ASG	AWS	PutScheduledUpdateGroupAction; pre-scheduled min/max/desired
ECS service	AWS	Application Auto Scaling PutScheduledAction
MIG	GCP	scalingSchedules on the autoscaler
VMSS	Azure	Autoscale FixedDate profile
Database	AWS/GCP/Azure	Monitor-only. ZopNight surfaces sizing recommendations (connection-pool math, headroom, suggested tier) but never modifies the database.

How the math works

You give ZopNight one of two inputs:

1. Multiplier: “I expect 4× baseline traffic”
2. Expected requests: “I expect 50,000 RPS at peak”

The capacity engine combines this with:

• Current baseline capacity per target
• Recent activity log signal (last 30 days)
• Existing autoscaler policy min/max/target

…and computes per-target scaledMin / scaledMax / scaledDesired. You can override any of these at step 2 of the wizard before scheduling.

Wizard flow

1. Define the event

   Name, target scope (resources, groups, or specific cloud accounts), start time, end time, timezone. Name is required and shows up in notifications.

2. Pick the capacity input

   Multiplier or expected requests. The wizard previews the per-target scaled values immediately; no save needed for the preview.

3. Review per-target overrides

   ZopNight pre-fills scaledMin / scaledMax / scaledDesired per target. You can edit any cell. The cost preview tile updates live.

4. Review DB impact (monitor-only)

   If the event scope includes databases, ZopNight shows a sizing recommendation (connection-pool math, suggested tier) but does not modify them. Implement the DB changes via your DBA flow before the event.

5. Schedule

   Confirm. ZopNight writes cloud-native scheduled actions on every target; no polling, no agent.

Lifecycle

Event state machine: draft → scheduling → scheduled → scaling_up → active → scaling_down → completed. Cancellation is terminal; once cancelled, an event cannot be re-scheduled (create a new one). Concurrent schedule requests for the same event are rejected.

State	What it means
draft	Wizard not yet submitted
scheduling	ZopNight is writing scheduled actions to cloud
scheduled	All cloud-side actions written; waiting for start time
scaling_up	Start time reached; cloud is provisioning capacity
active	At scaled capacity; event window in progress
scaling_down	End time reached; restoring original capacity
completed	Restored. Audit log row written.
cancelled	Terminal. Original capacity restored.
failed	Terminal. Investigate via event log.

Rollback

The originalMin / originalMax / originalDesired are snapshotted when the event is scheduled. Whether the event completes normally, you cancel it mid-flight, or it fails. ZopNight restores the original values.

For provider quirks ZopNight handles for you:

• GCP cancel uses Autoscalers.Update with ForceSendFields:["ScalingSchedules"] to actually delete the schedule (PATCH would silently leave stale schedules).
• AWS ASG cancel sweeps every zopnight-event-* scheduled action so no orphans leak on partial failures.
• AWS ECS cancel calls DeleteScheduledAction for every schedule ID and joins errors so partial failures name every action that failed.

Cost preview

The wizard shows a cost estimate at step 3 with an Estimated badge. It’s based on the pricing cache and the scaled capacity; actuals will differ if traffic exceeds the scaled max or comes in under the scaled min.

For the post-save view, GET /v1/event-readiness/{id}/cost-estimate (Bearer-authenticated, same as the other API endpoints) returns the same shape. Use this when you want a cost view on an already-scheduled event without re-opening the wizard.

Notifications

Four events fire to the attached notification channel:

• Event scheduled: schedule written successfully
• Event start: scaling_up reached
• Event end: completed with original capacity restored
• Event failure: failed state with the error and the rollback status

Audit log

Every state transition is in the audit log per target. When something looks off (“why did this VMSS not scale up at 9am?”) the audit row will have the cloud API response that caused it.