# Step Scaling: A Practical Guide > Step scaling is an autoscaling policy that defines tiered scaling adjustments based on how far a metric deviates from a threshold, allowing faster reaction to large bursts. Source: https://zop.dev/learn/step-scaling Published: 2026-07-01 · Author: avinash-gaurav · Tags: zopnight, learn, step-scaling --- Step scaling is an autoscaling policy that defines tiered scaling adjustments based on how far a metric deviates from a threshold, allowing faster reaction to large bursts. That is the textbook definition. In practice, Step Scaling is less a product you buy and more a discipline you run, a set of small, repeatable habits that compound into real savings over months. This guide covers what it is, why it matters, and how to put it into practice without a six-month rollout. ## Why Step Scaling matters Step Scaling shows up on almost every cloud-cost roadmap because it is where visibility turns into money. Dashboards and reports tell you where spend is going; Step Scaling is the practice of doing something about it. The teams that get value from it treat it as an operating rhythm rather than a one-off cleanup project, the difference between a bill that drifts down and stays down versus one that snaps back the moment attention moves elsewhere. ## How to put it into practice Start with the highest-leverage, lowest-risk action and build from there. For most teams that means scheduling non-production resources to run only during working hours, then adding idle detection to catch what's unused even during the day, then rightsizing what's genuinely over-provisioned. Each step is measurable, reversible, and safe to trial on non-production first. ZopNight operationalizes exactly this: it discovers the resources, surfaces the opportunities with a dollar estimate attached, and, where it is safe, acts on them automatically through scheduling and guided remediation, so the practice runs continuously instead of depending on a quarterly spring-clean. In practice that looks like [scheduling AWS EC2](https://zop.dev/zopnight/aws/ec2) to business hours, and it is exactly the execution gap that separates ZopNight from dashboard-first tools like [CloudHealth](https://zop.dev/compare/cloudhealth-vs-zopnight). ## How ZopNight schedules non-production resources The loop that does this is deliberately mechanical, and it starts read-only. You connect your cloud provider with a read-only role, and ZopNight discovers every non-production resources across your regions and accounts. It records a per-action permission verdict for each one, so you can see where it can list a resource but not yet stop it, and you review that inventory, filter it by status or type, and search for the specific resources you care about before anything is scheduled. Scheduling itself is a cron you write once in plain terms, stop at 7 PM, start at 8 AM on weekdays, pinned to your timezone so the jobs fire at local business hours rather than UTC. A weekly 24-hour grid shows the schedule visually so you catch gaps and overlaps before you save, and an estimate of active versus inactive hours appears before you commit. Resources attach individually or bundle into groups like "dev-cluster" or "staging-db" so a whole environment follows one cadence. Actions run in dependency order, so a database comes up before the app server that depends on it. When something needs to stay up, an override forces a non-production resources ON or OFF for a defined window, carries a reason so teammates understand why it exists, and expires automatically so nothing is left running by accident. If a start or stop fails, ZopNight retries up to three times and falls back to a dead-letter queue rather than silently dropping the action, and every state change lands in an audit trail that records whether a schedule, an override, or a specific user triggered it. ## Getting started Getting started is intentionally low-stakes: - Connect your cloud provider with a read-only role. Nothing is scheduled or changed at this stage. - Let ZopNight discover your non-production resources and review exactly what it found, filtered by account, region, and status. - Create a schedule in your timezone and attach the non-production resources or groups you want it to cover. - Watch the first cycle run, with Slack, Teams, or Google Chat notifications on every start, stop, and failure, then layer in idle cleanup and guided rightsizing. Production stays excluded by default throughout, and because discovery and recommendations are read-only, you can prove the value before you enable a single action. ## Frequently asked questions ### Why does ZopNight refuse Replace on step scaling with more than 2 adjustments? Step scaling with many adjustments cannot be reconstructed from a serialised rawSpec because the per-step calibration is workload-specific. ZopNight refuses Replace to avoid silent loss; Adopt-as-is remains available. ### When should I prefer step scaling over target tracking? When traffic burst latency is a problem and target tracking does not react fast enough. Step scaling can scale by larger increments on larger deviations, reducing the time to absorb a spike.