Does Cloud Scheduler use the same cron syntax as Linux?

Yes — Google explicitly implements standard 5-field unix-cron syntax, making it one of the more portable cloud schedulers if you're migrating expressions directly from a Linux crontab.

Can I set a timezone for a Cloud Scheduler job?

Yes, and it's effectively required — every job has an explicit IANA timezone field, so there's no UTC-only ambiguity like some other cloud schedulers.

What's the difference between Cloud Scheduler and the old App Engine cron.yaml?

cron.yaml is a legacy App Engine-specific mechanism with its own English-like schedule syntax, tied to a single App Engine app. Cloud Scheduler is the modern, standalone service using real unix-cron syntax and can target any HTTP endpoint or Pub/Sub topic, not just App Engine.

Cloud Scheduler

Google Cloud Scheduler Guide

Google Cloud Scheduler is GCP's fully managed cron job service, notable for using standard 5-field "unix-cron" syntax directly — unlike AWS's Quartz-derived format — while adding first-class IANA timezone support and the ability to trigger HTTP endpoints, Pub/Sub topics, or App Engine services.

Syntax Notes

Standard 5-field unix-cron syntax, identical to Linux cron, with a required, explicit IANA timezone (e.g. America/New_York) set per job rather than assuming UTC.

Examples

Create a scheduled HTTP job (gcloud CLI)

gcloud scheduler jobs create http nightly-report \
  --schedule="0 2 * * *" \
  --uri="https://example.com/run-report" \
  --time-zone="America/New_York"

Every 15 minutes, business hours, weekdays

*/15 9-17 * * 1-5

Gotchas

Cloud Scheduler jobs require a target (HTTP endpoint, Pub/Sub topic, or App Engine service) at creation time — unlike a crontab entry, you can't create a bare schedule without wiring it to something concrete first.
Failed HTTP targets are retried according to a configurable retry policy, which can cause a job to appear to run more often than its schedule suggests if the endpoint is flaky — check the retry configuration, not just the cron expression, when a job seems to over-fire.
The legacy App Engine cron.yaml mechanism (a separate, older feature) uses its own schedule syntax ("every 24 hours", "every monday 09:00") that is not standard cron — don't confuse it with Cloud Scheduler's unix-cron format.

Best Practices

Always set --time-zone explicitly rather than relying on a default, since Cloud Scheduler's default project timezone may not match what you expect.
Use Pub/Sub as the target when the downstream work is asynchronous or needs reliable delivery — it decouples the schedule from a single HTTP endpoint's availability.
Set a reasonable max retry count and backoff for HTTP targets — the default retry behavior can mask a genuinely broken endpoint as an intermittent scheduling issue.

Frequently Asked Questions

Does Cloud Scheduler use the same cron syntax as Linux?: Yes — Google explicitly implements standard 5-field unix-cron syntax, making it one of the more portable cloud schedulers if you're migrating expressions directly from a Linux crontab.
Can I set a timezone for a Cloud Scheduler job?: Yes, and it's effectively required — every job has an explicit IANA timezone field, so there's no UTC-only ambiguity like some other cloud schedulers.
What's the difference between Cloud Scheduler and the old App Engine cron.yaml?: cron.yaml is a legacy App Engine-specific mechanism with its own English-like schedule syntax, tied to a single App Engine app. Cloud Scheduler is the modern, standalone service using real unix-cron syntax and can target any HTTP endpoint or Pub/Sub topic, not just App Engine.

Related Tools

Platform Guides

Cron syntax for Linux, Kubernetes, AWS, and more

Azure Functions Timer Trigger Guide

How Azure Functions timer triggers use NCRONTAB syntax: the 6-field seconds-first format, UTC defaults, and common configuration examples.

Quartz Scheduler Cron Guide

Quartz Scheduler's 6/7-field cron syntax for Java applications: the L, W, and # special characters, and how it differs from standard cron.