Environment
I am troubleshooting an isolated, non-production Google Cloud setup.
- Cloud Scheduler region: “europe-west1”
- Cloud Run Job region: “europe-southwest1”
- Schedule: “*/15 * * * *”
- Time zone: “Etc/UTC”
- Target: HTTP POST to the Cloud Run v2 Jobs “:run” API, authenticated with OAuth.
Observations on 17 October 2026 (UTC)
During five scheduled slots at approximately 20:30, 20:45, 21:00, 21:15 and 21:30 UTC, Cloud Scheduler logs showed “AttemptStarted” and “AttemptFinished” entries. Each finished attempt reported HTTP 200.
Five Cloud Run Job executions were also observed. Each showed “succeededCount=1” and a completion timestamp. Cloud Run audit logs contained five “Jobs.RunJob” events referencing those executions.
However, some execution creation/start timestamps precede the corresponding Scheduler “AttemptStarted” log timestamps. We could not establish exact causal correlation using the available audit output.
State after pausing the Scheduler
The subsequent “gcloud scheduler jobs describe” output showed:
- “state: PAUSED”
- “status.code: -1”
- “scheduleTime” absent
- “lastAttemptTime” absent
The Console also displayed “Has not run yet”, despite the successful attempts in the logs.
Questions
1. Is “status.code=-1” expected for a paused Scheduler job after attempts returned HTTP 200?
2. Why might “scheduleTime” and “lastAttemptTime” be absent when attempt logs exist?
3. What does “userUpdateTime” represent in this situation?
4. What is the recommended way to correlate Scheduler attempts with Cloud Run v2 “Jobs.RunJob” audit events and execution resources?
5. Does “Has not run yet” indicate expected behavior, stale Console state, or a discrepancy requiring investigation?
I am not assuming a service defect. I would like to understand the expected API and Console behavior and identify the minimum read-only evidence needed.
Both Scheduler jobs remain paused. No production resources, IAM permissions, canonical collector, models or historical data were changed.