Sizes and ranges
| Limit | Value |
|---|---|
| A message’s body and attributes together | 262,144 bytes (256 KiB) |
| Attributes per message | 10; keys 1 to 64 letters, digits and _ . -, not starting ezgh.; values up to 1,024 bytes |
| Messages per send, receive, acknowledgement or visibility change | 1 to 10 |
| A request body | 1 MiB |
| Queue names | 1 to 80 letters, digits, - and _, unique in the project |
| Message group and deduplication IDs | 1 to 128 letters, digits and _ . : - |
| Visibility timeout | 0 to 43,200 seconds (12 hours), 30 by default |
| Time in flight after one receive, extensions included | 12 hours |
| Retention | 60 seconds to 14 days, 4 days by default |
| Delay | 0 to 900 seconds; per message on standard queues only |
| A receive’s wait | 0 to 20 seconds |
maxReceiveCount |
1 to 1,000 |
| FIFO deduplication window | 5 minutes |
| A peek page | 1 to 100 messages, 20 by default |
| Message counts | Exact up to 100,000 per state |
| Subscriptions per queue | 1 |
A subscription’s batchSize, maxConcurrency and timeoutSeconds |
1 to 10 (10), 1 to 100 (10), 1 to 60 seconds (30) |
Store larger payloads elsewhere and send a reference to them.
Rate limits
| Limit | Default |
|---|---|
sendRequestsPerSecond |
3,000 send requests a second per standard queue, in bursts of up to 6,000 |
receiveRequestsPerSecond |
3,000 receive requests a second per standard queue, in bursts of up to 6,000 |
fifoSendRequestsPerSecond |
300 send requests a second per FIFO queue, in bursts of up to 600 |
fifoReceiveRequestsPerSecond |
300 receive requests a second per FIFO queue, in bursts of up to 600 |
organizationRequestsPerSecond |
10,000 send and receive requests a second across the organization, in bursts of up to 20,000 |
| Peeking | 10 requests a second per queue |
| Purging | Once every 60 seconds per queue |
| Invalid receipt handles | 100 a minute per client address |
ezgh queues limits, or GetLimits, shows the values in force
for a project, with any queue that has its own.
A request over a limit answers 429 with Retry-After. Each send or receive request carries up
to 10 messages, so batching raises the messages a second a queue can take.
Caps
| Limit | Default | Over it |
|---|---|---|
storedBytesPerProject |
10 GiB of messages stored in a project | Sends answer 429 storage_limit_exceeded with Retry-After: 60 until messages are acknowledged, expire or are purged |
inFlightPerQueue |
120,000 messages in flight per standard queue | Receives answer no further messages until some are acknowledged or visible again |
inFlightPerFifoQueue |
20,000 messages in flight per FIFO queue | The same |
To see the limits in force for a project, open Service quotas in the console, or
read them from the API (queues.limits.get). Each limit has a
name, the project’s value, a unit, a scope, and overrides changed for the organization
or for one queue. New limits may be added to the list. To raise a limit, contact support.
Service quotas
| Quota | Default | Over it |
|---|---|---|
queues.queues.perProject |
1,000 queues per project, dead-letter queues included | 409 quota_exceeded |
queues.subscriptions.perProject |
1,000 subscriptions per project | 409 quota_exceeded |
See and request quotas in Service quotas.
Usage
| Meter | Measures |
|---|---|
queues.api.requests |
Sends, receives, acknowledgements and visibility changes, each counted once per 64 KiB of messages it carries, and at least once |
queues.push.deliveries |
Push subscription delivery attempts |
queues.storage.byteHours |
Bytes of stored messages, sampled hourly |
They’re priced at $0 at launch and nothing is charged for them.
Suspended and deleted organizations
- While an organization is suspended or its deletion is pending, its subscriptions deliver nothing; messages wait in their queues.
- When a project or organization is deleted, its queues, subscriptions and messages are deleted.