Skip to content
Latchkey

gcloud logging read: Query Cloud Logging in CI

gcloud logging read fetches log entries matching a filter, the scriptable way to inspect Cloud Logging.

When a deployed service misbehaves, pulling its recent error logs into the pipeline output speeds up triage. The filter language scopes by resource, severity, and time.

What it does

gcloud logging read runs a Cloud Logging filter and returns matching entries, newest first. The filter uses fields like resource.type, severity, and timestamp; --freshness limits how far back to look.

Common usage

Terminal
gcloud logging read \
  'resource.type=cloud_run_revision AND severity>=ERROR' \
  --limit=20 --freshness=1h --format='value(textPayload)'
# logs for one Cloud Run service
gcloud logging read \
  'resource.labels.service_name="api" AND severity>=WARNING' \
  --limit=50

Flags

FlagWhat it does
<FILTER>Cloud Logging filter expression
--limit <n>Maximum entries to return
--freshness <dur>Only entries newer than this (e.g. 1h, 30m)
--order asc|descSort order by timestamp (default desc)
--format <fmt>Output format, e.g. value(textPayload)

In CI

Always set --limit and --freshness so a debugging step does not stream an unbounded log volume into the job output. Authenticate keylessly with Workload Identity Federation; the identity needs roles/logging.viewer.

Common errors in CI

"INVALID_ARGUMENT: ... unparseable filter" means a syntax error, often a missing quote around a string value. "PERMISSION_DENIED ... logging.logEntries.list" needs roles/logging.viewer. An empty result usually means --freshness is too short or resource labels in the filter do not match the actual resource type.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →