GCP Cloud Logging Pricing: Ingestion, Retention, Query Costs, and Log Buckets

Reviewed by CloudCostKit Editorial Team. Last updated: 2026-06-18. Editorial policy and methodology.

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

Log Cost Calculator Log Ingestion Cost Calculator Log Retention Storage Cost Calculator Log Search Scan Cost Calculator

Logging costs are predictable when you treat logs like data, but the first budgeting decision is whether Cloud Logging cost is mainly being created by ingestion volume, retention policy, or repeated query and scan behavior. The page gets much easier to trust once you separate the Cloud Logging bill itself from the systems that analyze or archive logs after routing.

Quick pricing read

Cloud Logging pricing is not one generic "search your logs" fee. The first bill boundary is whether the log entry is stored in a Cloud Logging bucket at all. After that, the main Cloud Logging-native charges are ingestion into log bucket storage, retention beyond the included period, and any bucket-level storage pattern created by routing the same log into multiple destinations. Querying in Logs Explorer does not behave the same way as routed analysis in BigQuery or downstream SIEM tools, so those paths should not be blended into one line item.

  • Ingestion is usually the main paid surface: Cloud Logging charges for logs streamed into log bucket storage for indexing, querying, and analysis, with the first 50 GiB per project per month free for standard logging storage.
  • Retention becomes a second charge only after the included period: default bucket retention does not create the same long-tail storage bill as extending retention beyond 30 days.
  • Log buckets change ownership: if logs are routed into multiple buckets, the project that stores those buckets carries the storage charge for each stored copy.
  • Query and analysis paths must stay separated: Logs Explorer usage is not the same budget line as routed analysis in BigQuery, Pub/Sub pipelines, or external SIEM tooling.
  • Vended network logs and routed analytics can change the shape: network telemetry, bucket choices, and routed destinations can make a logging estate look more expensive or cheaper than one blended average suggests.

This page was updated on 2026-06-18 against the current Google Cloud Observability pricing page, Cloud Logging bucket documentation, and Cloud Logging analytics guidance.

Inside the Cloud Logging bill vs beside the Cloud Logging bill

  • Inside the Cloud Logging bill: ingestion into Cloud Logging bucket storage, retained data beyond the included period, bucket-level storage ownership, and any separate storage behavior created by routing logs into multiple buckets.
  • Beside the Cloud Logging bill: BigQuery analysis, Pub/Sub fan-out, SIEM ingestion, Cloud Storage archive copies, and broader observability tooling that consumes logs after they leave the bucket path.
  • Why this matters: BigQuery, Pub/Sub, and SIEM pipelines belong beside the Cloud Logging bill, because a team can have a modest Cloud Logging bill and still create a large downstream logging estate elsewhere.

0) Inventory sources (do not blend)

List the sources that can dominate volume and model them separately.

  • Ingress/access: very high volume, moderate size.
  • Firewall/WAF: can be high volume and high size (rule metadata).
  • Audit/security: lower volume but required retention.
  • Application logs: depends on log level and request volume.

1) Ingestion (GB)

Ingestion is the core driver. If you have usage exports, use them. If not, estimate from event rate and payload size. For most teams, this is the first place to look before debating retention or analytics tooling.

Tools: Log ingestion, Estimate GB/day guide.

  • Model baseline + peak: incident traffic and verbose logging can create a peak month.
  • Sample bytes/event for the top sources instead of using one blended average.
  • Keep ordinary application logs, load balancer logs, audit logs, and firewall or network logs separated because they rarely share the same size or retention profile.

2) Retention (GB-month)

Retention is a storage multiplier. In steady state, stored volume is roughly the last N days of logs, so retained GB is approximately GB/day × retention days. For Cloud Logging specifically, you should separate the included retention window from extended retention, because the economics change once you deliberately keep logs longer than the default bucket behavior.

Tools: Retention storage, Tiered log storage.

  • Keep a short hot window for troubleshooting and archive only what you must keep long-term.
  • Split retention by log class (access vs audit vs app logs) instead of one global retention setting.
  • Validate which logs remain in Cloud Logging buckets versus which are exported elsewhere, because the exported copy creates a different storage bill.

3) Query and scan (dashboards + alerts)

Query and analysis behavior can still matter, but keep the budget boundary clean. Logs Explorer behavior inside Cloud Logging is not the same as routed queries in BigQuery or downstream SIEM tools. Dashboards and alert rules can scan far more data than you expect once logs leave the basic bucket workflow and enter heavier analytics paths.

Tool: Log scan/search.

  • A dashboard refreshing every minute is 1,440 refreshes/day.
  • Prefer queries that filter early and use narrower time windows.
  • If a team is really paying for routed analytics rather than Cloud Logging-native usage, move that spend beside the Cloud Logging bill instead of hiding it here.

Worked estimate template (copy/paste)

  • GB/day ingested = sum over sources(events/day × bytes/event ÷ 1e9)
  • GB/month ingested = GB/day × 30.4 (baseline + peak)
  • Retained GB ~= GB/day × retention days (split by source)
  • GB scanned/month = scans/day × GB/scan × 30.4 (dashboards + alerts)

Common pitfalls

  • Turning on high-volume sources without measuring their payload sizes.
  • Using one blended event size that hides a dominant source (ingress/firewall).
  • Blending Cloud Logging storage with BigQuery, Pub/Sub, SIEM, or object-storage archive costs.
  • Keeping long retention everywhere by default.
  • Dashboards/alerts scanning wide windows repeatedly (query cost explosion).
  • Verbose logging during incidents (peak ingestion dominates the month).

How to validate

  • Sample payload sizes for top sources and compute bytes/event.
  • Validate which sources are enabled and disable/suppress the noisiest first.
  • Validate which log buckets actually store the data and which projects own those buckets.
  • Validate retention per log class and apply tiered storage if needed.
  • Audit whether analysis happens in Logs Explorer, BigQuery, or external SIEM tooling before assigning query costs.
  • Audit dashboard refresh intervals and alert windows (reduce repeated wide scans).

Related tools

All log tools Ingestion Tiered storage Scan Estimation checklist

Sources

Related guides

Azure Log Analytics pricing: ingestion, retention, and query costs
A practical model for Log Analytics-style costs: GB ingested, retention storage, and query/scan behavior. Includes a method to estimate log GB from event rate and payload size, plus a validation checklist for high-volume sources.
Cloud Armor pricing (GCP): model baseline traffic, attack spikes, and logging
A practical Cloud Armor estimate: baseline request volume plus an attack scenario (peak RPS × duration). Includes validation steps for spikes, rule footprint, and the secondary cost driver most teams miss: logs and analytics during incidents.
Cloud Functions pricing (GCP): invocations, duration, egress, and log volume
A practical Cloud Functions cost model: invocations, execution time, outbound transfer, and logs. Includes a workflow to estimate baseline + peak and validate retries, cold starts, and log bytes per invocation.
Cloud Monitoring metrics pricing (GCP): time series, sample rate, and retention
A practical metrics cost model: time series count (cardinality), sample rate, retention, and dashboard/alert query behavior. Includes validation steps to prevent high-cardinality explosions and excessive refresh patterns.
Pub/Sub pricing: deliveries, retries, fan-out, and payload transfer (practical estimate)
A practical Pub/Sub estimate: publish volume, fan-out (subscriptions), delivery attempts (retries), retention/replay scenarios, and payload transfer. Includes a worked template, pitfalls, and validation steps.
Cloud Spanner cost estimation: capacity, storage, backups, and multi-region traffic
Estimate Spanner cost using measurable drivers: provisioned capacity (baseline + peak), stored GB-month (data + indexes), backups/retention, and multi-region/network patterns. Includes a worked template, common pitfalls, and validation steps.

Related calculators

Log Cost Calculator
Estimate total log costs: ingestion, storage, and scan/search.
Log Ingestion Cost Calculator
Estimate monthly log ingestion cost from GB/day or from event rate and $/GB pricing.
Log Retention Storage Cost Calculator
Estimate retained log storage cost from GB/day, retention days, and $/GB-month pricing.
Log Search Scan Cost Calculator
Estimate monthly scan charges from GB scanned per day and $/GB pricing.

FAQ

What usually drives logging cost?
Cloud Logging cost is usually led by ingestion volume first. Retention becomes material after 30 days, and the surrounding analysis path matters when logs are routed into BigQuery, Pub/Sub, SIEM tools, or broader observability workflows.
How do I estimate quickly?
Estimate monthly ingestion first, then split what stays in log buckets, what is retained beyond 30 days, and what is routed to other destinations. Keep Cloud Logging-native charges separate from downstream analytics or archive costs.
What is the most common mistake?
The most common mistake is mixing Cloud Logging storage charges with downstream BigQuery, Pub/Sub, SIEM, or archive costs, then treating all of it as one logging number. Another common miss is ignoring one dominant log source such as load balancer, firewall, or audit logs.
How do I validate?
Validate top sources by volume, confirm which buckets actually store the logs, check retention by bucket, and verify whether queries happen inside Cloud Logging or in routed analytics systems such as BigQuery.
Last updated: 2026-06-18. Reviewed against CloudCostKit methodology and current provider documentation. See the Editorial Policy .