canonical: https://jentic.com/apis/googleapis.com/cloudscheduler

# Google Cloud Scheduler API

Cloud Scheduler is a fully managed enterprise-grade cron service for Google Cloud. The API lets you create, update, pause, resume, and run jobs that fire HTTP, App Engine, or Pub/Sub targets on a recurring schedule defined with standard cron syntax. It handles retries with exponential backoff and reports per-job execution state, replacing fragile self-hosted cron servers for batch ETL, billing rollups, and timed agent workflows.

## For AI agents

Schedule recurring HTTP, App Engine, or Pub/Sub jobs using cron expressions and pause, resume, or trigger them on demand. Lets agents own time-based automation across GCP without standing up a cron host.

## Scope

Does not run user code, queue ad-hoc tasks, or orchestrate multi-step workflows - use for time-based recurring triggers against HTTP, App Engine, or Pub/Sub targets only.

## Capabilities

- Create scheduled jobs that target HTTP endpoints, App Engine handlers, or Pub/Sub topics
- Pause and resume jobs around release windows or incident response
- Trigger a queued job to run immediately for testing or backfill
- Configure retry policy with exponential backoff and max attempts per job
- List and delete jobs across regions in a project

## Use cases

### Cron-Driven HTTP Webhooks

Replace self-managed cron boxes with managed schedules that POST to any reachable HTTPS endpoint. Cloud Scheduler signs the request with an OIDC or OAuth token from a service account and retries on failure with configurable backoff, making it suitable for nightly billing rollups, cache warmers, and reconciliation jobs that need to run on time without operators.

Example prompt: Create a Cloud Scheduler job that sends a POST to https://api.example.com/reconcile every day at 03:00 UTC with retries enabled

### Pub/Sub Fan-Out On a Schedule

Trigger downstream pipelines by publishing a message to a Pub/Sub topic on a fixed cadence. Cloud Scheduler jobs with a Pub/Sub target are ideal for orchestrating Cloud Functions, Cloud Run services, or Dataflow pipelines without coupling them to one another, and the schedule runs in the same region as the consumer to keep latency predictable.

Example prompt: Create a job that publishes {"action": "refresh"} to projects/acme/topics/data-refresh every 15 minutes

### Maintenance Window Pausing

Pause and later resume scheduled jobs around release windows or incident response so noisy cron firings do not pile up while a service is down. Cloud Scheduler stores the schedule state separately from the running schedule, letting an agent or runbook flip jobs off and back on with a single API call each.

Example prompt: Pause job projects/acme/locations/us-central1/jobs/billing-rollup, run the deployment, then call resume on the same job

### Agent-Triggered Scheduled Workflows

An AI agent can stand up a one-off recurring job to drive its own multi-step workflow - for example, polling a slow-moving data source every 30 minutes and stopping once a condition is met. Through Jentic, the agent searches for 'schedule a recurring job', receives the jobs.create schema, and provisions the job without learning the full Cloud Scheduler resource model.

Example prompt: Use Jentic to create a Cloud Scheduler job that triggers the agent's webhook every 30 minutes and call delete on the job once the workflow completes

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v1/{+name}/locations | List Cloud Scheduler locations available to the project |
| POST | /v1/{+name}:run | Trigger a job to run immediately |
| POST | /v1/{+name}:pause | Pause an active scheduled job |
| POST | /v1/{+name}:resume | Resume a paused job |
| POST | /v1/{+name}:cancel | Cancel an in-flight job execution |

## Key resources

- **Jobs** — Create, list, get, update, pause, resume, run, and delete scheduled jobs
- **Locations** — List the regions where Cloud Scheduler is available for the caller's project

## Why Jentic

- **Setup:** Wiring the Cloud Scheduler API by hand means setting up Google OAuth 2.0, minting short-lived tokens against the cloud-platform scope, and addressing each job by resource name against cloudscheduler.googleapis.com yourself. Through Jentic you install once, import the Cloud Scheduler API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** Cloud Scheduler puts the job resource name in the URL path (/v1/{+name}:run, /v1/{+name}:pause), so a rule can pin your agent to one job: it can run and pause that job and nothing else. You choose the operations it may call, so resume or cancel are not included unless you add them.
- **Credential handling:** Your Cloud Scheduler OAuth credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'schedule a recurring job' or 'pause a scheduled job', and Jentic returns the matching Cloud Scheduler operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Cloud Tasks API** — Queue-based asynchronous task dispatch instead of cron-based scheduling
- **Cloud Pub/Sub API** — Pub/Sub topics are a common Cloud Scheduler target for fan-out
- **Cloud Workflows API** — Multi-step orchestration that Cloud Scheduler can kick off on a cadence

## FAQ

### What authentication does the Cloud Scheduler API use?

It uses Google OAuth 2.0 with the https://www.googleapis.com/auth/cloud-platform scope. Through Jentic the OAuth client and refresh token live in your Jentic One instance and only short-lived access tokens are passed to the agent runtime.

### Can I trigger a scheduled job on demand with the Cloud Scheduler API?

Yes. Call the run method on /v1/{name}:run to fire a job immediately outside its normal schedule. This is the standard way to validate a job after creating or editing it.

### What are the rate limits for the Cloud Scheduler API?

Google enforces per-project quotas on jobs created and on administrative API calls per minute. Job execution itself is governed by the per-job retry configuration, not by the API quota - most projects can run thousands of jobs concurrently within the default limits.

### How do I create a recurring job through Jentic?

Search Jentic for 'schedule a recurring job', load the projects.locations.jobs.create schema, and execute a call against /v1/{parent}/jobs with the cron schedule, target, and timezone. Jentic returns the input schema so the agent fills only the fields it needs.

### Is the Cloud Scheduler API free?

Cloud Scheduler offers three free jobs per billing account per month and charges a small monthly fee per additional job. The API itself has no per-call charge beyond the job pricing.

### What target types does Cloud Scheduler support?

Each job can target an HTTP or HTTPS endpoint, an App Engine HTTP handler, or a Pub/Sub topic. Use HTTP targets with OIDC tokens to reach private Cloud Run or Cloud Functions services without exposing them publicly.

### Can I limit what my agent is allowed to do with the Cloud Scheduler API?

Yes. Because Jentic One is self-hosted, you write the rules that decide which operations and credentials your agent can use, and Cloud Scheduler puts the job name in the URL path (like /v1/{name}:run and /v1/{name}:pause), so a rule can pin the agent to a single job and let it only run and pause that one job. You pick the operations it may call, so actions such as resume or delete stay off limits unless you explicitly add them.