Harness CCM vs ZopNight: Idle AutoStopping or Timed Schedules

What Harness CCM does

Harness now calls the module AI and Cloud Costs (harness.io). It covers AWS, Azure, GCP and Kubernetes. Its headline automation is AutoStopping, which “detects idle VMs and Kubernetes workloads and stops them automatically, restarting on demand”. Around that sit a Commitment Orchestrator for Reserved Instances and Savings Plans, Asset Governance with “150+ out-of-the-box rules”, anomaly detection, and tracking of AI spend on OpenAI, Anthropic, Bedrock and Vertex.

The AutoStopping docs (developer.harness.io) list EC2, Auto Scaling groups, EKS, ECS services, RDS instances, AKS, Azure VMs, GCP instance groups and GKE. Rules combine idle thresholds with optional fixed schedules. Users reach stopped resources through a load balancer, a proxy or a direct IP and resources restart on demand.

An earlier version of this page said you must adopt the whole Harness platform to use CCM. The pricing page (harness.io/pricing) says otherwise. Its Enterprise plan lets you “choose any modules: mix and match”, and Cloud AI Cost Management is one of those modules. The Free plan covers Harness Open Source and Litmus Chaos only, not the cost module. No dollar figures are published.

Idle-triggered or clock-triggered

This is the real design difference. Harness AutoStopping waits for a resource to go idle, then stops it, and wakes it when traffic arrives through its proxy or load balancer. That suits resources with unpredictable use, such as a preview environment someone opens twice a week.

ZopNight’s schedules are clock-driven. You write cron expressions in an IANA timezone, preview them on a weekly grid, and attach them to resources or to groups. A group starts in a set order (storage, then databases, then compute, then apps) and stops in reverse, with a delay per resource. No traffic has to pass through ZopNight to wake anything. When someone needs a resource outside its hours, an override keeps it on for a set window, carries a reason, and expires on its own. The approach suits teams with predictable working hours, and it keeps the schedule readable by anyone who looks at it.

Choose Harness CCM if…

• Your non-production usage is irregular, and you want resources to wake when someone hits them rather than on a timetable.
• You already use Harness CI/CD, and one vendor and console matter to you.
• You want commitment orchestration and a large library of governance rules in the same module.

Choose ZopNight if…

• Your teams keep regular hours and you want predictable, auditable on and off times, with a group’s resources started in a set order (storage, then databases, then compute, then apps) and a delay per resource.
• You want Kubernetes handled at namespace level on EKS, GKE and AKS. Deployments and StatefulSets scale to zero and CronJobs are suspended, and HPAs and PDBs are put back on start.
• You schedule data platforms as well as infrastructure: Databricks clusters, pools and SQL warehouses, and Snowflake warehouses. See Snowflake warehouse scheduling.