---
cuppy_hub: gcp
cuppy_path: reference/messaging/cloud-tasks.md
cuppy_section: docs
cuppy_doc: PTE2-E006
cuppy_doc_uuid: 68a9e471-6be9-4084-8d9f-a868f8533129
cuppy_permalink: https://cuppy.io/gcp/d/PTE2-E006
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/messaging/cloud-tasks
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 6a5c28a686caf376125a68d914c9a1a1f84b34785f194d4cb47cb0b4054ee155
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Cloud Tasks

## 1. What it is

> "Cloud Tasks lets you separate out pieces of work that can be performed independently, outside of your main
> application flow, and send them off to be processed, asynchronously."

## 2. Two objects

| Object | What it is |
|---|---|
| **queue** | "a managed set of tasks with the **same target type and configuration**" |
| **task** | one unit of work: a unique name, its configuration, and an optional payload |

The queue carries the configuration. So **a queue is a policy**, and work needing different rates, retries or
targets needs different queues — not different task fields.

A task having a **unique name** is the detail that matters most in practice: it is what makes
de-duplication possible on the producer side, before the work is ever dispatched.

## 3. Two target types

1. **HTTP/S endpoints** — Cloud Run, GKE, Compute Engine, and **on-premises servers**;
2. **App Engine applications** — standard **second-generation** or flexible environments only.

The on-premises reach is worth noting for a hybrid migration: a Google Cloud queue can dispatch to a target
that has not moved yet.

## 4. The three controls, and why they are the reason to choose it

| Control | What it gives you |
|---|---|
| **rate limits** | control the **dispatch frequency** — protect a fragile downstream from a burst |
| **retry parameters** | per-queue handling of failed tasks |
| **scheduled delivery time** | "Schedule specific delivery times" — a task can be for later |

Those three are what a message bus does not give you per item. The decision rule:

| Choose | When |
|---|---|
| **Cloud Tasks** | each item is **a job for one endpoint**; you need to **throttle** the dispatch rate; or an item must run **at a specific future time** |
| **Pub/Sub** | the event may have **many** consumers, you want fan-out, high throughput, or ordering by key (`reference/messaging/pubsub.md`) |

*Recorded honestly:* the Cloud Tasks overview **does not itself compare the two** — it links a Cloud Scheduler
comparison instead. The rule above is the hub's reading from the two services' documented properties, and it is
labelled as such.

## 5. For a migration estimate

Cloud Tasks is the closest Google Cloud thing to "a worker queue with a rate limit and a delay", which on AWS
is SQS plus either a Lambda event-source mapping with concurrency controls or EventBridge Scheduler, and on
Azure is Storage queues or Service Bus plus scheduled enqueue. Because the Google Cloud service bundles the
rate limit and the schedule **into the queue**, a design arriving from either cloud often collapses two or
three components into one. Note the collapse explicitly in the estimate — see `guides/parity/messaging.md`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->