Score a Google Cloud estate on cost, reliability, security and operations, and see which pillar to fix first.
Each pillar is scored from coverage percentages you can read off Recommender, the organisation policy dashboard, Cloud Monitoring and your own repositories, then weighted with reliability and security carrying the most weight. Idle spend is penalised at four points per percent because it is pure waste with no offsetting benefit, so even a few percent drags the cost pillar down hard. One number makes an estate comparable month to month and across projects, and the weakest-pillar and quick-win outputs turn it into a single concrete next action rather than a dashboard nobody opens. Pair it with the per-service calculators here to put a monetary figure against each gap.
GCP Health Score
score = reliability × 0.30 + security × 0.30 + cost × 0.20 + operations × 0.20, where each pillar is a weighted blend of its coverage inputs and idle spend is penalised at four points per percent.
score = reliability × 0.30 + security × 0.30 + cost × 0.20 + operations × 0.20, where each pillar is a weighted blend of its coverage inputs and idle spend is penalised at four points per percent. Each pillar is scored from coverage percentages you can read off Recommender, the organisation policy dashboard, Cloud Monitoring and your own repositories, then weighted with reliability and security carrying the most weight. Idle spend is penalised at four points per percent because it is pure waste with no offsetting benefit, so even a few percent drags the cost pillar down hard.
One number makes an estate comparable month to month and across projects, and the weakest-pillar and quick-win outputs turn it into a single concrete next action rather than a dashboard nobody opens. Pair it with the per-service calculators here to put a monetary figure against each gap.
This calculator takes 11 inputs: Steady-state compute covered by commitments, Spend on idle or orphaned resources, Projects with a budget and alerting, Production workloads spread across zones, Datastores with a tested restore, Projects under organisation policy constraints, Bindings granted to groups rather than individuals, Sensitive datastores using customer-managed keys, Services with metrics, logs and alerts, Services with a defined SLO, Resources managed as infrastructure as code. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Because zonal redundancy protects against an infrastructure failure while a restore protects against every other failure — a bad deployment, a corrupting bug or a deletion. Multi-zone architecture faithfully replicates corrupted data to every zone.