# GCP Bigtable Instance Idle

> Bigtable instances whose request count averages and peaks at zero across a window with at least 30 days of coverage are flagged as idle, provided cluster CPU load stays under the 2% internal-work veto. Savings equal the instance's full monthly cost; an absent request-count series abstains.

Source: https://zop.dev/integrations/gcp/recommendations/gcp-bigtable-instance-idle
Updated: 2026-08-19

---

## Request count, with CPU load as a veto

- MetricsAware (SetMultiMetrics): BigtableRequestCount read by name off the nested UID→metricName view; BigtableCPULoad read the same way as a corroborating "still doing internal work" veto (cpuActive, threshold 2.0%). No tag/Metadata fallback; the previous operations tag was a producerless field the discoverer never wrote and has been removed, and the rule abstains when BigtableRequestCount is absent.
- Producer fix: the Cloud Monitoring filter previously keyed BigtableRequestCount/BigtableCPULoad on the table/cluster resource labels against the Bigtable instance ID, but those labels are a table name and a cluster ID respectively and never equal the instance ID, so the filter matched no series and both metrics were permanently unproduced (rule always abstained fleet-wide). Fixed to key on the instance resource label (present on both bigtable_table and bigtable_cluster, equal to the instance ID). Because one instance can have multiple tables/clusters sharing that label, the mappings also now set aggregation.crossSeriesReducer (REDUCE_SUM for request count across tables, REDUCE_MAX for cpu_load across clusters) with groupByFields=resource.label."instance", so a multi-table or replicated (multi-cluster) instance resolves to one instance-wide series instead of an arbitrary single one.

## Why zero requests refunds the whole instance

Concrete or abstain (cost-driven idle). Skips when the priced run-rate cost is unknown/zero (resource.pricing). Fires only when BigtableRequestCount averages/peaks at zero over a ≥30d-covered window *and* BigtableCPULoad does not corroborate active internal work (compaction/replication/GC) at or above 2.0%: CurrentCostUSD = SavingsUSD = cost, OptimizedCostUSD = 0. The rule abstains (returns nil) when pricing is unknown, BigtableRequestCount is absent, any request activity is observed, the CPU-corroboration veto fires, or coverage is below the 30d floor; never a fixed or fabricated estimate.

## Exporting data before you delete

1. Verify no applications depend on this Bigtable instance
2. Export data if needed using cbt export (CLI) or the Dataflow Cloud Bigtable to Avro Files on Cloud Storage template
3. Delete the instance to stop charges
4. Consider Bigtable autoscaling for variable workloads

## One instance-wide series across tables and clusters

BigtableRequestCount (primary, server/request_count, SUM-reduced across tables) + BigtableCPULoad (corroborating veto, cluster/cpu_load, MAX-reduced across clusters), both 30d (aggregator: backend/aggregator/internal/metrics/gcp/monitoring.go)