# Target Tracking Scaling: A Practical Guide > Target tracking scaling is an autoscaling policy type that automatically adjusts capacity to keep a chosen metric (CPU, memory, request count) at a target value. Source: https://zop.dev/learn/target-tracking-scaling Published: 2026-07-01 · Author: avinash-gaurav · Tags: zopnight, learn, target-tracking-scaling --- Target tracking scaling is an autoscaling policy type that automatically adjusts capacity to keep a chosen metric (CPU, memory, request count) at a target value. That is the textbook definition. In practice, Target Tracking 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 Target Tracking Scaling matters Target Tracking 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; Target Tracking 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 ### When is target tracking the wrong choice? When traffic spikes faster than the cooldown allows the autoscaler to react. Burst-heavy workloads often need step scaling for fast scale-out plus target tracking for steady-state, or predictive scaling for known patterns.