GCP Health Score Calculator
Score a Google Cloud estate on cost, reliability, security and operations, and see which pillar to fix first.
Inputs
Sustained use discounts are automatic; committed use discounts are the part you have to decide.
Unattached disks, idle addresses, forgotten dev clusters and endpoints nobody calls.
A backup nobody has restored is a hypothesis, not a backup.
Overall Health Score
52.4/ 100
Grade
D — Weak
Cost Pillar
52.2/ 100
Reliability Pillar
56.8/ 100
Security Pillar
51.3/ 100
Operations Pillar
48.0/ 100
Fix This First
Operations — get metrics, logs and an SLO onto every production service and bring resources under infrastructure as code
Cheapest Improvement Available
Delete unattached Persistent Disks, unused static addresses and idle load balancer rules — no negotiation or commitment needed
Step by step
Values used
Steady-state compute covered by commitments = 40 %; Spend on idle or orphaned resources = 9 %; Projects with a budget and alerting = 55 %; Production workloads spread across zones = 65 %; Datastores with a tested restore = 50 %; Projects under organisation policy constraints = 70 %; Bindings granted to groups rather than individuals = 45 %; Sensitive datastores using customer-managed keys = 30 %; Services with metrics, logs and alerts = 60 %; Services with a defined SLO = 25 %; Resources managed as infrastructure as code = 55 %
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.
Overall Health Score
= 52.4 / 100
Grade
= D — Weak
Cost Pillar
= 52.2 / 100
Reliability Pillar
= 56.8 / 100
Security Pillar
= 51.3 / 100
Operations Pillar
= 48.0 / 100
How it works
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.
Formula
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.
- cost pillar
- Commitment coverage, a sharp penalty for idle spend, and budget alerting
- reliability pillar
- Zonal spread weighted with tested restores, which matter more
- security pillar
- Organisation policy coverage, group-based bindings and customer-managed keys
- operations pillar
- Telemetry coverage, SLO coverage and infrastructure-as-code coverage
Frequently Asked Questions
How is GCP Health Score calculated?
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.
Why does GCP Health Score matter?
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.
What values do I need to enter?
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.
Why is a tested restore weighted higher than zonal spread?
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.
You might also need
- Compute Engine Cost CalculatorCommonly used together
- Cloud Monitoring Cost CalculatorCommonly used together
- GCP Logging Cost CalculatorCommonly used together
- GCP IAM Policy Size CalculatorCommonly used together
- Cloud Run Cost CalculatorAlso in Google Cloud
- Cloud Load Balancer CalculatorAlso in Google Cloud