Schedule Cloud Functions to Run on a Cron with Cloud Scheduler (2026)

Cloud Scheduler can trigger Cloud Functions on a cron schedule by acting as a managed cron service that sends HTTP requests to your function’s endpoint.

Let’s see it in action. Imagine you have a Cloud Function named daily-report-generator that needs to run every day at 3 AM UTC to compile user activity reports.

First, ensure your Cloud Function is deployed and accessible via an HTTP endpoint. You can deploy it using gcloud functions deploy:

gcloud functions deploy daily-report-generator \
  --runtime nodejs16 \
  --trigger-http \
  --entry-point generateReport \
  --region us-central1 \
  --allow-unauthenticated

In this example, --trigger-http makes it an HTTP-triggered function, and --allow-unauthenticated means it doesn’t require authentication for simplicity (in production, you’d want to secure this). The --entry-point generateReport specifies the JavaScript function to execute.

Now, let’s set up Cloud Scheduler to trigger this function. You’ll need to create a service account that Cloud Scheduler will use to invoke your function. This service account needs the roles/cloudfunctions.invoker role.

gcloud iam service-accounts create scheduler-invoker \
  --display-name "Cloud Scheduler Invoker"

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member "serviceAccount:scheduler-invoker@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
  --role "roles/cloudfunctions.invoker"

Replace YOUR_PROJECT_ID with your actual Google Cloud project ID.

Next, create the Cloud Scheduler job:

gcloud scheduler jobs create http daily-report-job \
  --schedule "0 3 * * *" \
  --uri "https://us-central1-YOUR_PROJECT_ID.cloudfunctions.net/daily-report-generator" \
  --http-method GET \
  --oidc-service-account-email "scheduler-invoker@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
  --oidc-token-audience "https://us-central1-YOUR_PROJECT_ID.cloudfunctions.net/daily-report-generator" \
  --time-zone "UTC" \
  --project YOUR_PROJECT_ID

Let’s break this down:

• daily-report-job: The name of your Cloud Scheduler job.
• --schedule "0 3 * * *": This is the cron syntax. It means "at minute 0 of hour 3, every day of the month, every month, every day of the week."
• --uri "https://us-central1-YOUR_PROJECT_ID.cloudfunctions.net/daily-report-generator": This is the invocation URL of your Cloud Function. You can find this in the Cloud Functions console or by running gcloud functions describe daily-report-generator --region us-central1 --format="value(httpsTrigger.url)".
• --http-method GET: The HTTP method Cloud Scheduler will use. This should match what your Cloud Function expects (or be one it handles).
• --oidc-service-account-email: The service account Cloud Scheduler will impersonate to authenticate its request.
• --oidc-token-audience: This is crucial for authenticated Cloud Functions. It specifies the intended recipient of the OIDC token, which must match your function’s URL.
• --time-zone "UTC": Specifies the timezone for the schedule.

When this job runs, Cloud Scheduler will generate an OIDC token for the specified service account, send it in the Authorization: Bearer <token> header of an HTTP request to your function’s URI, and your function will execute.

The real power of Cloud Scheduler comes from its reliability and integration within GCP. It handles retries, provides logs, and offers fine-grained scheduling options beyond basic cron. It’s not just a wrapper around a cron daemon; it’s a managed service that ensures your scheduled tasks execute predictably. You can configure retry policies directly on the job, for instance, to automatically re-attempt a function invocation if it fails.

One common pitfall is misconfiguring the --oidc-token-audience. If your function is configured to require authentication (which is the default and recommended for production), Cloud Scheduler must provide a valid OIDC token, and the audience claim in that token must match the URL your function is served from. If they don’t match, you’ll likely see a 401 Unauthorized error from Cloud Functions, even if your service account has the invoker role.

The next step in managing scheduled tasks is often handling distributed state or ensuring idempotency for your triggered functions, especially if retries occur.