Bigtable instances that served zero requests for 30 days
What does ZopNight detect here?
Bigtable instances are flagged when `bigtable.googleapis.com/server/request_count` shows zero requests across every table for 30 days and cluster CPU load stays under 2%. Bigtable bills provisioned nodes every hour whether or not anything reads them, so ZopNight reports the instance's full monthly cost as the saving.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1244 |
| Category | idle |
| Severity | medium |
| Metric | bigtable.googleapis.com/server/request_count |
| Threshold | zero requests and CPU load under 2% |
| Evaluation window | 30d |
| Source | ZopNight |
| Permissions used | bigtable.instances.list · monitoring.timeSeries.list |
Where it applies
Nodes bill whether or not anyone reads them
Bigtable charges for provisioned compute, not for traffic. Google’s Bigtable pricing states that you are charged each hour for the maximum number of nodes that existed in that hour, that node charges apply regardless of node usage and even when a cluster is inactive, and that each provisioned node is billed for at least one hour. Storage is billed separately, and a multi-cluster instance pays for a full copy of the data in every cluster.
An instance nobody queries is therefore billing its full node count around the clock. Leftover test instances and tables from finished migrations are the usual culprits.
Checking request traffic yourself
List instances in the project:
gcloud bigtable instances listThen, in Metrics Explorer, chart bigtable.googleapis.com/server/request_count for the instance
over 30 days, summed across tables, alongside bigtable.googleapis.com/cluster/cpu_load. A flat
zero on requests with near-idle CPU matches this rule.
Two signals that must agree
- Request count summed across the instance’s tables is zero, on both the average and the peak, over the 30-day window.
- Cluster CPU load, taken from the busiest cluster, stays under 2% on average and at peak. CPU above that means Bigtable is still doing internal work such as replication or compaction.
- The metric history covers the full 30 days.
- The instance has a known monthly cost.
Why ZopNight might not flag an idle-looking instance
Any single request in the window clears it. If request data is missing entirely, the rule does not assume zero; it stays silent. The same applies when the history is shorter than 30 days, as for a new instance, or when the instance cannot be priced.
The full run-rate is the saving
saving = current monthly instance costcost after deletion = 0Scaling down to fewer nodes is a partial alternative if the instance must stay.
Retiring the instance
- Confirm with the owning team that no application, Dataflow job or replication target uses it.
- Export anything worth keeping with the Bigtable to Cloud Storage Avro Dataflow template, so the data survives outside the instance.
- Delete it:
gcloud bigtable instances delete INSTANCE_ID. - For instances that stay, enable autoscaling so node count follows load.