Pub/Sub Topic
Does ZopNight manage 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.
Rules that fire on Pub/Sub Topic
No active rule family targets Pub/Sub Topic today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
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.