Monitor Google Cloud Scheduler and Cloud Run jobs

Cloud Scheduler starts the job; Cloud Run runs it. Either can fail without anyone looking: the scheduler’s service account loses permission, the job’s tasks exhaust their retries, or the schedule is paused and forgotten. A heartbeat check catches all of these: the job reports to Pingstack after it succeeds, and Pingstack alerts you when that report doesn’t arrive on time.

1. Create a heartbeat check that matches the schedule

Cloud Scheduler uses standard five-field cron and a timezone you choose per job. Find both in the console under Cloud Scheduler, or with:

gcloud scheduler jobs describe nightly-report-trigger --location=us-central1

Create a heartbeat check and set its schedule to Cron with the same expression and timezone. See schedules and timezones.

Set a grace period that covers the job’s runtime, container start-up, and any task retries. Attach a notification group.

2. Store the ping URL in Secret Manager

Copy the location’s ping URL from the check in Pingstack and store it as a secret, without putting it in your shell history:

read -rs URL
printf '%s' "$URL" | gcloud secrets create pingstack-nightly-report --data-file=-
unset URL

Then expose it to the job as an environment variable. The job’s service account needs the Secret Manager Secret Accessor role on the secret.

gcloud run jobs update nightly-report --region=us-central1 \
  --set-secrets=PINGSTACK_PING_URL=pingstack-nightly-report:latest

3. Report after the job succeeds

Chain the report onto the job’s command, so it runs only when the work exits successfully:

gcloud run jobs update nightly-report --region=us-central1 \
  --command=sh \
  --args='-c,./run-report && curl --fail --silent --show-error --max-time 10 --retry 3 "$PINGSTACK_PING_URL"'

If the image has no shell or curl, report from the end of your program instead, after the work succeeds. A failed run sends nothing, and Pingstack alerts you when the deadline passes.

If your job runs several tasks in parallel, report from each task with its own named location, or from a single task chosen with CLOUD_RUN_TASK_INDEX, so one successful task can’t hide another’s failure.

4. Confirm the first report

Run the job once:

gcloud run jobs execute nightly-report --region=us-central1 --wait

Open the check in Pingstack and confirm the location received a heartbeat and shows a next deadline. To confirm the schedule itself can start the job, use Force run on the Cloud Scheduler job.

Optional: report a number

Append a count the job produces as a numeric value, for example with --get --data-urlencode "value=$COUNT" on the curl call, then set warning and critical thresholds on the check.

Cloud Run services and functions

If the schedule calls an HTTP endpoint on a Cloud Run service or Cloud Function instead of a job, report at the end of the request handler, after the work succeeds and before returning the response.

Why a healthy job might still alert

• Retries. A task that succeeds on a later attempt reports late.
• Paused schedule. A paused Cloud Scheduler job never runs. Pingstack alerts, which is usually what you want.
• Permissions. If the scheduler’s service account can’t run the job, the trigger fails before the job starts. Cloud Scheduler’s logs show the error.
• Timezone mismatch. The check and the scheduler job’s timezone must agree.

If alerts still don’t match what you expect, see troubleshooting monitoring.