A few simple ideas before we meet the service.

Many tasks are about time, not events

Some work in software starts because something happened, such as a customer placing an order. Other work starts simply because a certain time has arrived. Examples are generating a daily sales report, cleaning up old files every night, refreshing cached data every few minutes, sending a weekly newsletter, running a data pipeline each morning or checking the health of an external service every five minutes. These are called scheduled or batch tasks, and almost every real system has them.

The old way: cron

For decades, administrators used a tool called cron on Linux servers. A cron entry says, in a compact format, “run this command at these times.” It works well, but it lives on one particular machine. If the machine is switched off, replaced, overloaded or forgotten, the schedule silently stops. Teams then had to keep a server alive just to run a few clocks, patch it, monitor it and worry about what happens if it fails or if two copies run at once.

The cloud way: a managed scheduler

A managed scheduler moves the clock out of your servers into a service that is always on, highly available and maintained by someone else. Your actual work can then run anywhere, on whatever service suits it best, and the scheduler’s only job is to knock on the door at the right time.

A fully managed cron job service in Google Cloud.

Cloud Scheduler is a fully managed service that lets you create jobs that run on a schedule you define. Each job contains a schedule, a target and some settings about retries and authentication. When the schedule fires, Cloud Scheduler sends a request to the target. That target might be a web address, a Cloud Run or Cloud Functions service, a message topic in Pub/Sub, or other targets, and from there your own code does the real work.

It is often described as cron as a service. You get the familiar schedule format, but without servers to run, with built-in retries, logging and monitoring, and with secure ways to identify itself to the services it calls. Importantly, Cloud Scheduler does not run your code itself. It simply triggers something else. This is a deliberate design: the scheduler stays small and reliable, and your workload runs in a service built for running workloads.

A short dictionary of Cloud Scheduler words.

Five little fields describe almost any repeating time.

A cron schedule has five fields, separated by spaces, which stand for minute, hour, day of the month, month and day of the week, in that order. Each field can hold a specific number, a star meaning every possible value, a list of values, a range, or a step such as every fifteen. You do not need to memorize the format; the idea is easy to read once you see examples described in words.

Cloud Scheduler also lets you choose the time zone for each job. This matters because “9 a.m.” in Mumbai and “9 a.m.” in New York are different moments. Also keep in mind that some regions change their clocks for daylight saving time, which can make a job fire an hour earlier or later in absolute terms, and may skip or repeat a run on the day the clocks change. For jobs where this matters, consider using a time zone without daylight saving, or testing the behavior around the change.

The smallest repeat interval is one minute, so Cloud Scheduler is not designed for second-by-second triggering. For very frequent or event-driven work, use messaging or other tools instead.

What happens when the alarm rings.

flowchart LR
    CS[Cloud Scheduler job fires] --> H[HTTP or HTTPS endpoint]
    CS --> P[Pub/Sub topic]
    CS --> A[App Engine HTTP endpoint]
    H --> CR[Cloud Run service or job]
    H --> CF[Cloud Functions]
    H --> WF[Workflows execution]
    H --> EXT[Your own app or an external service]
    P --> S1[Subscriber: function]
    P --> S2[Subscriber: container]
    P --> S3[Subscriber: pipeline]
        

What happens between the clock striking the time and your work starting.

sequenceDiagram
    participant CS as Cloud Scheduler
    participant T as Target Service
    participant L as Cloud Logging
    CS->>T: Scheduled request with credentials
    alt Success within deadline
        T-->>CS: Success response
        CS->>L: Log success
    else Error or timeout
        T-->>CS: Error response or no reply
        CS->>CS: Wait using backoff
        CS->>T: Retry request
        T-->>CS: Eventually success or retries exhausted
        CS->>L: Log final result
    end
        

Things go wrong, and the scheduler should handle that gracefully.

Networks hiccup, services restart and databases are briefly busy. A good scheduler retries, but sensibly. Cloud Scheduler lets you configure how many times to retry, the total time window in which retries are allowed, and how long to wait between attempts. The waiting time can grow after each failure, a pattern called exponential backoff, so a struggling service is not hammered with requests. The attempt deadline decides how long a single attempt may take before it is counted as failed.

At-least-once delivery and idempotency

An important truth about schedulers and most distributed systems is that they promise at-least-once delivery. That means the target will be triggered at least one time, but in rare situations, for example when a response is lost on the way back, the same scheduled run could be delivered more than once. Your target must therefore be idempotent, which is a technical word meaning that doing the same thing twice has the same effect as doing it once. For example, “set today’s report status to generated” is safe to repeat, while “add one hundred rupees to the balance” is not.

flowchart TD
    A[Job fires] --> B{Target responds with success in time?}
    B -->|Yes| C[Run recorded as successful]
    B -->|No| D{Retries left and time window open?}
    D -->|Yes| E[Wait using backoff]
    E --> A2[Retry request]
    A2 --> B
    D -->|No| F[Run recorded as failed, alert can fire]
        

An open address that does work for anyone who calls it would be a gift to attackers.

Never leave targets open to the whole internet

If a scheduled endpoint can be called by anyone, then anyone on the internet could trigger your nightly cleanup, your billing run or your data export whenever they like. Protected targets should accept calls only from identities you trust.

Authenticating the job with a service account

Each job can be configured with a service account, an identity for software. Cloud Scheduler uses that identity to attach a signed token to the request. For targets in Google Cloud, such as Cloud Run and Cloud Functions, an OpenID Connect identity token is commonly used, and the target is set to allow only that specific service account to invoke it. For calling Google Cloud’s own programming interfaces, an OAuth access token is used instead. Check the documentation to match the token type to the target.

Least privilege

The service account used by a job should have only the permission to invoke its specific target, nothing more. Do not reuse a powerful general-purpose account. Also control who may create or change jobs, because a person who can edit a job can make it call something different, with the job’s identity.

Protecting sensitive data in requests

Avoid placing passwords, keys or personal data in job headers or bodies, since they are stored with the job and visible to people who can read it. If the target needs secrets, let the target fetch them from a secret manager using its own identity.

flowchart TD
    A[Dedicated service account per job or purpose] --> B[Signed token attached to each request]
    B --> C[Target allows only that service account to invoke it]
    C --> D[Least-privilege permissions, no powerful shared accounts]
    D --> E[No secrets or personal data in job headers or bodies]
    E --> F[Audit logs and review of who can edit jobs]
        

Everyday tasks in the life of a scheduled job.

Where Cloud Scheduler earns its keep.

Google Cloud has several services that sound similar. Here is how they differ.

A very common and powerful pattern combines these tools. Cloud Scheduler provides the clock, and it starts a workflow, which orchestrates several steps across services. Or Cloud Scheduler publishes a message, and subscribers do the work in parallel. Each tool does what it is best at.

flowchart LR
    CS[Cloud Scheduler: the clock] --> WF[Workflows: the choreographer]
    WF --> S1[Step 1: extract data]
    WF --> S2[Step 2: transform data]
    WF --> S3[Step 3: load to warehouse]
    WF --> S4[Step 4: notify team]
    CS --> PS[Pub/Sub topic]
    PS --> SUB1[Subscriber A]
    PS --> SUB2[Subscriber B]
        

Habits that make schedules boring and reliable.

When a scheduled job fails, you want to know quickly and fix it calmly.

Cloud Scheduler writes logs for each attempt, including whether it succeeded, the response status and any error. These flow into Cloud Logging, where you can search, filter and create log-based alerts. Combine this with logs from the target itself, which show what happened after the request arrived.

Where your jobs live and what to remember about limits.

Jobs are created in a specific location, a Google Cloud region. Choose a region close to your targets, and follow any rules about where your data and operations must reside. Cloud Scheduler is a managed, highly available service, but, as with all services, it has quotas, such as limits on the number of jobs per project and rules about the minimum interval, which can change over time. Check the current quotas page when you plan to create many jobs.

Because Cloud Scheduler guarantees at-least-once delivery, rather than exactly-once, and because the exact second of firing can vary slightly, design your systems with those facts in mind. For work where timing must be precise to the second, or where tasks must happen thousands of times per minute, use other tools designed for that.

Cheap by design, with the real cost usually in what the job triggers.

Cloud Scheduler is typically priced per job per month, with a small free allowance of jobs for each billing account. Pricing and allowances can change, so check Google Cloud’s pricing page for current numbers. The price of the scheduler itself is usually tiny compared with the cost of what it starts: the compute used by the function or container, the data pipelines, the queries and the network traffic.

A balanced view.

Lessons from teams who run hundreds of scheduled jobs.

Best practices at a glance

Anti-patterns to avoid

No. It triggers other services at the times you define. Your code runs in a service such as Cloud Run, Cloud Functions or your own application, which Cloud Scheduler calls.

The standard five-field cron format for minute, hour, day of month, month and day of week, together with a time zone you select for each job.

One minute. For finer timing or very high rates, use queues, messaging or application-level logic instead.

It is possible in rare cases, because delivery is at-least-once and retries can occur. Make your targets idempotent so repeated triggers are harmless.

Configure the job with a service account so it attaches a signed token, and configure the target to accept calls only from that identity. Do not expose sensitive endpoints publicly.

When several systems need to react, when you want buffering and decoupling, or when the work should be handled by subscribers rather than by a single endpoint answering within the deadline.

Cloud Scheduler fires at recurring times you define. Cloud Tasks manages queues of individual tasks created by your code, with rate limits and retries, to be run now or at a chosen later time.

Yes. You can trigger a job immediately without changing its schedule, which is ideal for testing permissions, targets and responses.

Jobs follow the chosen time zone, so a run at a local time may shift in absolute terms, and may be skipped or repeated on the days clocks change. Test critical jobs, or choose a time zone without daylight saving.

Cloud Scheduler writes logs for every attempt. Create log-based or monitoring alerts for failures, and also alert when an expected run did not happen at all.

Cloud Scheduler gives your cloud applications a dependable sense of time. It is a fully managed cron service that fires at the schedule you define, in the time zone you choose, and sends a request or a message to the target you pick, with retries and logs built in. Its strength is simplicity: it triggers, and other services do the work. To use it well, make your targets idempotent and quick to respond, authenticate calls with least-privilege service accounts, set retry and timeout settings that fit the job, watch out for time zones and daylight saving, avoid piling all jobs on the same minute, and alert on both failures and missing runs. Combined with Pub/Sub, Workflows and queues, it becomes the dependable clock at the center of automation in Google Cloud.