Scheduling Cloud Functions with Cloud Scheduler: Setup, IAM, and Cost Tips

Why schedule a Cloud Function?

Many batch jobs need to run on a regular cadence—nightly reports, data clean‑ups, or cache warm‑ups. Managing a VM or a Cloud Scheduler‑based cron adds operational overhead. Cloud Scheduler can invoke an HTTP target, and a Cloud Function provides a lightweight, serverless endpoint that scales to zero when idle.

Create a minimal Cloud Function

The function below logs the invocation time and returns a 200 response. It is intentionally simple so you can focus on the scheduling wiring.

# main.py
def hello_scheduler(request):
    '''Logs the request time and returns 200.'''
    import datetime, json
    now = datetime.datetime.utcnow().isoformat() + 'Z'
    entry = {'message': 'Scheduler triggered', 'time': now}
    print(json.dumps(entry))  # goes to Cloud Logging
    return ('OK', 200)

Deploy the function

Make sure the Cloud SDK is authenticated and you have the Cloud Functions Developer role on the project.

gcloud functions deploy scheduler-function \
  --runtime python310 \
  --trigger-http \
  --allow-unauthenticated \
  --project YOUR_PROJECT_ID \
  --region us-central1

After deployment note the HTTPS trigger URL, which looks like https://REGION-PROJECT_ID.cloudfunctions.net/scheduler-function.

Set up the Cloud Scheduler job

The scheduler service account needs permission to invoke the function. Grant the Cloud Functions Invoker role to that account.

gcloud functions add-iam-policy-binding scheduler-function \
  --member='serviceAccount:YOUR_SA@PROJECT_ID.iam.gserviceaccount.com' \
  --role='roles/cloudfunctions.invoker' \
  --project YOUR_PROJECT_ID \
  --region us-central1

Now create the job. Adjust the cron expression to your desired frequency.

gcloud scheduler jobs create http my-scheduler-job \
  --schedule '*/5 * * * *' \
  --uri https://REGION-PROJECT_ID.cloudfunctions.net/scheduler-function \
  --http-method GET \
  --oidc-service-account-email YOUR_SA@PROJECT_ID.iam.gserviceaccount.com \
  --oidc-token-audience https://REGION-PROJECT_ID.cloudfunctions.net/scheduler-function \
  --project YOUR_PROJECT_ID \
  --region us-central1

Verify execution and handle retries

Once the job is active, check logs in two places:

• Cloud Logging: filter by resource.type="cloud_function" and resource.labels.function_name="scheduler-function" to see the printed JSON entry.
• Cloud Scheduler: open the job detail page and view the Logs tab for delivery attempts and any retry events.

If the function returns a non‑2xx status, Cloud Scheduler will retry according to its retry configuration (default: up to five attempts with exponential backoff). To prevent duplicate work, design the function to be idempotent—for example, by checking a record’s existence before updating it or by using deterministic writes.

Trade‑offs and limitations

• Cost: You pay for each scheduler job execution (a few‑tenths of a cent) plus the Cloud Function execution charges based on runtime and memory.
• Quota: The default limit is 100 scheduler jobs per project. Request a quota increase if you need more.
• Idempotency: Automatic retries can cause the same logic to run multiple times unless the function is safe to repeat.
• Latency: There is a small delay (typically under a second) between the scheduled time and the function start.

Actionable next steps

1. Deploy the test function as shown.
2. Create a scheduler job with a one‑minute schedule (* * * * *) to verify end‑to‑end delivery.
3. Confirm that logs appear in both Cloud Logging and Cloud Scheduler within a minute of the trigger.
4. Adjust the schedule, retry policy, or function logic to match your production workload.
5. Monitor usage on the Cloud Scheduler quotas page and the Cloud Functions billing reports to keep costs predictable.