Scheduled Analytics on GCP: Cloud Run Jobs, Scheduler, OIDC and Safe Reporting
A scheduled report is a distributed system in miniature. The trigger, compute identity, data queries and delivery channel each need an explicit contract if the job is to be reliable and secure.
Choose the right execution primitive
Use a Cloud Run job for finite batch work and a Cloud Run service when the scheduler must invoke an HTTP endpoint. Define timeouts, retries and concurrency from the workload's data and API limits rather than accepting defaults.
Authenticate every hop
Give Cloud Scheduler a dedicated service account and use OIDC for authenticated HTTP targets. Give the workload a separate runtime identity with read access only to required analytics data and secret access only to required delivery credentials.
Make runs idempotent
Derive a run key from report type and reporting period. Store run state so retries do not send duplicate reports. Queries should use explicit time zones and closed intervals to avoid gaps or overlap around midnight and daylight changes.
Keep delivery secrets out of telemetry
Load webhook or API credentials at runtime from Secret Manager. Validate destination domains, avoid printing request URLs and redact error objects that may contain headers. Rotate a delivery credential immediately if it appears in a log or chat.
Observe business and platform outcomes
Monitor job executions, latency, failures and retry exhaustion, but also record report period, row count and delivery status. A technically successful job that queried an empty or incomplete window is still a failed report.
Test failure modes deliberately
Exercise expired credentials, missing IAM, API throttling, malformed responses, partial query results and duplicate triggers. Route exhausted runs to an actionable alert containing the run ID and diagnostic location, never the secret value.