Policy simulator

Check your rotation schedule before deploying. Enter your RotationPolicy configuration and fleet size, and instantly see which day each node gets rotated — and whether every node makes it before its expireAfter backstop fires.

When to use

Before choosing a maintenance window — test whether the window is wide enough for your fleet
When adjusting minRotationChances, cooldownAfter, or expireAfter — see the effect immediately
To understand why ThroughputBurstShortfall or ThroughputBelowArrival warnings fire
To visualize how a synchronized batch (all nodes the same age) interacts with your schedule

How to read the result

Green nodes complete their rotation before their expireAfter deadline — the graceful path works.
Orange nodes are rotated via the surge-less forceful fallback (if enabled) — still inside the window, still PDB-respecting, but without make-before-break.
Red nodes reach their expireAfter deadline before the controller can rotate them — they fall back to Karpenter's native forceful expiration.

A healthy configuration should show all green. Orange means throughput is tight but controlled. Red means the schedule needs widening.

Scope

The simulator models rotation starts and completions, including forceful fallback. It does not model failures (surge timeouts, retryBackoff, failurePause). The result is a best-case projection, not a production guarantee.

How it works (technical)

This page runs the controller's own Go code — the ageThreshold derivation, candidate-selection predicate, and start gates — compiled to WebAssembly. The simulator and the controller share one implementation and cannot drift apart (a CI check guards this).

Policy

The YAML is authoritative — it is what the simulator decodes, exactly as a cluster would. The form edits it in place.

Maintenance window — when rotation may START

Timezone IANA timezone for the window (e.g. Asia/Tokyo)

DaysWhich weekdays the window recurs on

Window start Time the window opens (24h)Window end Time the window closes (24h)

Derivation — how early a node is picked

minRotationChances (K) How many windows a node gets before expiry (K)ageThreshold "auto" or a Go duration string using h/m/s units (e.g. "120h", "1h30m")

Surge — how one rotation runs

provisioningEstimate Expected provisioning time (throughput forecast)drainEstimate Expected drain time (throughput forecast)readyTimeout Max wait for the surge node to become ReadycooldownAfter Pause between successive successful rotations Forceful fallback Delete surge-less if graceful can't finish in time

Fleet

The nodes to simulate. The generator creates a batch; you can also edit individual rows.

expireAfter (NodePool template) Node lifetime before Karpenter force-expires it (e.g. 336h)terminationGracePeriod (NodePool template) How long Karpenter waits before force-killing pods (e.g. 24h)

Nodes Number of nodes to generate (1–50)Spread (e.g. 168h, 30m, 2h30m) Time between first and last node creation (e.g. 168h = 1 week)First created at Creation timestamp of the first node (ISO 8601)

Name	Created at	expireAfter	tGP

Simulated actual durations (what the virtual world does)

These are NOT the policy estimates: the estimates are the forecast, these are what actually happens. Moving them apart is the interesting case — a policy whose C is optimistic because its estimates are too low.

Provisioning blank = policy estimate: Drain blank = policy estimate:

Horizon

A multiple of the LONGEST node lifetime (expireAfter). Not "generations": staggered createdAt, per-node overrides, window waits and cooldown all break that equivalence.

Lifetime coverage

2026-02-17T00:00:00.000Z

Exact horizon (ISO 8601)

Start End

Diagnostics

No diagnostics.

Policy simulator ​

When to use ​

How to read the result ​