Event readiness

Event readiness (Automate → Event Readiness) gets you ready for planned spikes such as Black Friday, a product launch, or a load-test window without paying for weeks of idle headroom. 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 calculation reads your autoscaler policy posture and recent activity rather than guessing at headroom.

Automate → Event Readiness: each planned event with its dates, scaling lead time, traffic multiplier, targets, and lifecycle state.

Before you start

• A Read + Write cloud account for each target, because ZopNight writes cloud-native scheduled actions on them. See Read-only vs read + write.
• The event details: a name, the targets (resources, groups, or cloud accounts), start and end time, timezone, and either a traffic multiplier or an expected peak request rate.
• Optional: a notification channel subscribed to Event Readiness lifecycle alerts, if you want start, end, and failure notices. See Notifications.

How it works

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

ZopNight scales 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
• Existing autoscaler policy min/max/target

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

Cost preview

The wizard shows a cost estimate alongside the capacity step, 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 /orgs/{orgID}/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 reopening the wizard.

Create an event

Go to Automate → Event Readiness and click Create Event.

1. Define the event

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

2. Pick the capacity input and review each target

   Multiplier or expected requests. ZopNight pre-fills scaledMin / scaledMax / scaledDesired per target straight away, with no save needed, and you can override any cell. The cost preview tile updates live as you edit.

3. 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.

4. Schedule

   Confirm, and ZopNight writes cloud-native scheduled actions on every target. Nothing polls and no agent is installed.

Lifecycle

Event state machine: draft → scheduling → scheduled → scaling_up → active → scaling_down → completed. Cancellation is terminal; once cancelled, an event cannot be rescheduled (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 the cloud
scheduled	All cloud-side actions written; waiting for start time
scaling_up	Start time reached; the 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	The event could not complete. Investigate via the event log, then use Retry on the event card.

Rollback

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

ZopNight handles these provider quirks 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.

Notifications

Three events fire to the channels subscribed to Event Readiness lifecycle alerts (Settings → Notifications, Automation category):

• 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 recorded per target in the event’s history, and changes you make to the event land in the audit log. When something looks off (“why did this VMSS not scale up at 9am?”), start with that target’s history.

Troubleshooting

Next steps