# Pub/Sub Topic

> Pub/Sub bills per TiB for message throughput (data published, data delivered to each subscription, and retained messages) with no idle charge on the topic itself. ZopNight inventories topics via Cloud Asset Inventory and attributes throughput spend from the BigQuery billing export; snapshot and retained-acknowledged-message storage bill separately. Unacknowledged messages are retained for up to 7 days by default.

Source: https://zop.dev/integrations/gcp/pubsub-topic
Updated: 2026-08-19

---

Pub/Sub topics provide global, serverless messaging billed per TiB of data published, delivered, and retained. Retention settings and abandoned subscriptions are the usual cost culprits.

## Every subscription multiplies the delivery meter

Pub/Sub charges per TiB in three places: data published into a topic, data delivered out to subscribers, and message storage for whatever is retained. The delivery meter is the one that multiplies. A topic with five subscriptions delivers every message five times and bills for each delivery independently, so fan-out is a cost decision as much as an architectural one. Storage charges arrive through retention: unacknowledged messages persist for up to 7 days by default, retained acknowledged messages bill separately when that feature is enabled, and topic snapshots hold their own billable copy. An idle topic with no traffic costs nothing, which makes Pub/Sub waste behavioral rather than structural.

## Throughput spend traced back to topics

ZopDev inventories topics via Cloud Asset Inventory and attributes throughput spend from the BigQuery billing export, so message-volume charges land against the topics generating them instead of pooling in an unattributed messaging line. Topics have no lifecycle to schedule: nothing runs, so nothing stops. The savings levers are subscription hygiene and retention settings rather than any start/stop action.

## Where messaging money quietly multiplies

The classic leak is the abandoned subscription: a consumer service is decommissioned but its subscription remains, so messages keep being delivered, unacknowledged, and retained for the full default window, billing on both the delivery and storage meters for a reader that no longer exists. Second is retain-acknowledged-messages enabled during a replay investigation and never disabled. Third is debug fan-out: extra subscriptions created to tap production traffic for testing, each one doubling delivery volume for that topic.

## Tracing a topic's consumers in the console

Google Cloud console → Pub/Sub → Topics lists topics with their subscription counts. Opening a topic shows each subscription and its backlog. A subscription whose oldest unacked message age keeps climbing toward the retention limit has lost its consumer and is the first cleanup candidate.