# Event readiness

> Pre-scale infrastructure for planned traffic spikes (sales, launches, load tests) with rollback built in.

Source: https://zop.dev/docs/zopnight/optimization/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 page listing planned events with traffic multiplier, target count, and status (Draft, Active, Scheduled, Completed, Cancelled, Failed), each with Schedule, Edit, Cancel, or View actions](https://storage.googleapis.com/zopdev-blog-resources/1/files/originals/20260707/93f13531-5153-4d7b-a062-373670214f81-eventreadiness.png)

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

**Tip**

Use **multiplier** when the event is a percentage uplift on normal traffic; sales, launches.
Use **expected requests** when you have a hard target; load tests, traffic re-route windows.

## Wizard flow

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

**Pick the capacity input**

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

**Review per-target overrides**

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

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

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