CloudHealth vs ZopNight: Policy Governance or Scheduling Depth
CloudHealth is a long-standing governance platform, now sold by Broadcom. ZopNight is built around a recurring start/stop loop and fixes you can approve.
What CloudHealth does
Ownership. CloudHealth is a Broadcom product. The old cloudhealthtech.com domain now redirects to Broadcom’s FinOps pages, where the product is titled “CloudHealth by Broadcom” (broadcom.com). Its documentation now lives on Broadcom TechDocs.
Coverage. Broadcom’s getting-started index (TechDocs) has quick-start guides for AWS, Azure, GCP, Oracle Cloud, Alibaba Cloud, data center and bring-your-own data, plus container governance.
Automation. CloudHealth is not a reporting-only tool with no automation, as an earlier version of this page claimed. Its policies can take actions, and “you can configure actions to run at a specific time and date”. Actions include stopping or terminating AWS instances, stopping and deallocating Azure VMs, and stopping GCP compute instances, each “on its own or after an approver has signed off” (Getting started with policies).
Pricing. We found no public pricing.
How the automation models differ
CloudHealth’s actions hang off policies: a rule matches resources, and an action runs at a configured time, optionally after approval. That fits governance work, such as “stop anything untagged in this account on Friday”.
ZopNight treats the schedule as a first-class object. A schedule is a set of cron expressions in an IANA timezone, and it fires every day it applies. You attach it to resources or to resource groups. It shows a weekly 24-hour grid and an estimate of active and inactive hours before you save. Groups start in a set order with per-resource delays. Overrides keep a resource on or off for a window, carry a reason, and expire on their own. Every state change records whether a schedule, an override or a named user caused it.
| Capability | ZopNight | CloudHealth |
|---|---|---|
| Clouds | AWS, GCP, Azure | AWS, Azure, GCP, Oracle, Alibaba, data center |
| Stopping instances | Recurring cron schedules with overrides | Policy actions at a set time and date |
| Approval before action | Admin gate for destructive remediation | Optional approver sign-off on actions |
| Databases and K8s namespaces on a schedule | RDS, Cloud SQL, Azure flexible servers; EKS/GKE/AKS namespaces | Not stated in the policy actions we read |
Choose CloudHealth if…
- You need one governance layer across Oracle, Alibaba or data-center estates as well as AWS, Azure and GCP.
- Your organisation already buys from Broadcom, and consolidating vendors matters.
- Your automation needs are policy-shaped: find matching resources, then act on a date after sign-off.
Choose ZopNight if…
- Your savings depend on a daily rhythm, with dev and staging off every evening and weekend, and you want that rhythm expressed once, in local time.
- You schedule more than VMs: RDS and Cloud SQL, Azure MySQL and PostgreSQL flexible servers, EKS, GKE and AKS clusters, and individual Kubernetes namespaces. See Azure VM scheduling for the stop-versus-deallocate detail.
- You want recommendations with evidence attached and a remediation wizard that validates the result after it acts.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
Who owns CloudHealth now?
Broadcom. As of 24 September 2026 cloudhealthtech.com redirects to Broadcom's FinOps pages, and the product is branded CloudHealth by Broadcom.
Can CloudHealth stop instances automatically?
Yes. CloudHealth policy actions can stop AWS instances, stop and deallocate Azure VMs, and stop GCP instances at a configured time and date, optionally after approval. The difference with ZopNight is the model: recurring cron schedules with groups, ordering and expiring overrides.
Can I try ZopNight without write access to my accounts?
Yes. A read-only connection gives you discovery, billing and recommendations, and lets you attach schedules. Starting and stopping resources, including scheduled execution, needs a read and write connection.