Google Cloud Logging: Logs Explorer and gcloud Guide

Last verified on Nov 8, 2026.

Google Cloud services write to Cloud Logging, and you read the result in the Logs Explorer in the console, with gcloud logging read in a terminal, or through the API. All three use the same Logging query language. This guide covers the language, the commands, Cloud Run specifics, and sinks for routing logs out.

Reading Logs in the Logs Explorer

Open Logs Explorer in the Google Cloud console and choose a project, folder, or organization. What you see depends on the resources searched, the time range, your IAM roles, and your filters. The page has a primary toolbar, a query pane, a fields pane, a timeline, and a results pane. The toolbar holds the time-range selector, a Query library of saved and recent queries, a Share link button, and Stream logs, which shows new entries as Logging stores them.

You need at least the Logs Viewer role (roles/logging.viewer) to see the _Default view. Private Logs Viewer (roles/logging.privateLogViewer) is required to see all entries in _Required and _Default.

Build the query in the query pane. For example, adding severity>=ERROR limits the results to entries of at least that severity.

The Logging Query Language

A query is a boolean expression over fields of the log entry. The pieces you need:

• Comparisons have the form FIELD OP VALUE, such as resource.type = "cloud_run_revision". Operators are =, !=, <, <=, >, >=, : (has, a substring match), and =~ for regular expressions.
• Joining: AND, OR, and NOT must be capitalized. Lowercase and is treated as a search term. Two statements side by side are joined with an implicit AND. Group OR clauses in parentheses.
• Case: comparisons ignore letter case, except for regular expressions and the logical operators.
• Nested fields use dots: jsonPayload.httpRequest.protocol, resource.labels.service_name. Quote path components that contain special characters, as in labels."compute.googleapis.com/resource_id".
• Global restrictions: a bare value like "timeout" checks every field and payload. That works, but Google warns that global restrictions can be slow.
• A query cannot exceed 20,000 characters.

Three queries that cover most days:

resource.type="cloud_run_revision" AND resource.labels.service_name="checkout" AND severity>=ERROR

jsonPayload.message:"connection reset" AND timestamp>="2026-11-08T09:00:00Z"

resource.type="gce_instance" AND NOT textPayload:healthcheck

Making Queries Fast

Logging always indexes resource.type, resource.labels.*, logName, severity, timestamp, insertId, operation.id, trace, httpRequest.status, and labels.*. Lead with those. Google's guidance is to narrow by log name, resource, and time first, avoid OR where an AND will do, and prefer textPayload:"Hello Kitty" over a bare global string. The built-in SEARCH function uses indexes where global and substring matches cannot.

Reading Logs with gcloud

gcloud logging read takes the same filter as its first argument, and returns entries newest first. By default it only looks back one day (--freshness=1d), and that default works only with descending order and filters that have no timestamp condition.

# Errors and above for a Cloud Run service, last hour
gcloud logging read \
  'resource.type="cloud_run_revision" AND resource.labels.service_name="checkout" AND severity>=ERROR' \
  --freshness=1h --limit=50 --project=my-project

# Search payload text, as JSON
gcloud logging read 'textPayload:SyncAddress' --limit=10 --format=json

# A specific time window
gcloud logging read 'timestamp>="2026-11-07T00:00:00Z" AND timestamp<="2026-11-07T23:59:59Z"'

# From a specific log bucket and view
gcloud logging read "" --bucket=my-bucket --location=global --view=_AllLogs --limit=5

You can also read from a folder or organization with --folder or --organization, or from several resources with --resource-names.

Cloud Run Logs

Cloud Run produces three kinds of logs, all sent automatically to Cloud Logging: request logs (services only), container logs from your code, and system logs under varlog/system. Container logs are picked up when written to stdout or stderr, to files under /var/log, to syslog (/dev/log), or through a Cloud Logging client library.

In the console, open the service, then its Logs tab, which shows request and container logs for all revisions and filters by severity. Jobs have the same tab, and you can drill into one execution. For Logs Explorer, pick Cloud Run Revision for a service or Cloud Run Job for a job.

From the CLI, for a service:

# Console-style single-line format
gcloud run services logs read checkout --limit=10 --project my-project

# Raw entries from Cloud Logging
gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=checkout" --project my-project --limit 10

# Live tail (Preview, needs the log-streaming component)
gcloud beta run services logs tail checkout --project my-project

If a service writes one line of serialized JSON to stdout, Cloud Logging parses it into jsonPayload. Plain text lands in textPayload. Google's Cloud Run example includes a severity key and a message key, which it describes as the default display field. See structured logging and the JSON logging guide.

New instance starts are logged in varlog/system as Starting new instance. Reason: REASON - DESCRIPTION, with reasons AUTOSCALING, DEPLOYMENT_ROLLOUT, and MANUAL_OR_CUSTOMER_MIN_INSTANCE. That is the first place to look for cold start questions.

Retention and Sinks

The _Required bucket keeps its logs for 400 days and that period cannot be changed. The _Default bucket and user-defined buckets keep logs for 30 days unless you set a custom period between 1 and 3650 days. See log retention.

To send logs elsewhere, create a sink. The Log Router checks each entry against every sink's inclusion filter and then its exclusion filters, and routes matches to the destination.

gcloud logging sinks create my-sink \
  pubsub.googleapis.com/projects/my-project/topics/my-topic \
  --log-filter='resource.type="cloud_run_revision" AND severity>=WARNING' \
  --exclusion='name=drop-health,filter=httpRequest.requestUrl:"/healthz"'

Without a --log-filter, a sink matches everything. A sink has a service account called the writer identity, and you must grant it permission on the destination, for example publisher on a Pub/Sub topic.

Searching Google Cloud Logs with Sazabi

Sazabi, an AI-native observability and security platform, receives Cloud Logging entries through a sink and Pub/Sub. In the self-managed path from the Sazabi Google Cloud docs, you create a Pub/Sub topic and pull subscription, a sink that routes to the topic, and an OpenTelemetry Collector with the googlecloudpubsub receiver exporting to your Sazabi intake URL. Sazabi can instead provision the sink, topic, and subscription for you from a service account key. Google bills for Pub/Sub delivery, so give the sink a filter that forwards only what you need. See the Google Cloud integration and OpenTelemetry Collector pages.