Build Pub/Sub subscription configurations with dead-letter policies, retry settings, and push delivery.
Build Pub/Sub subscription configurations with dead-letter policies, retry settings, push delivery, and exactly-once processing.
Required Fields
nametopicackDeadlineSecondsOutput will appear here...Build a Pub/Sub subscription with dead-letter policy, retry backoff, ordering, and push delivery settings. ackDeadlineSeconds caps at 600 (10 minutes); if your handler routinely takes longer, use modifyAckDeadline in code rather than just cranking this value, since a stuck consumer holding a long deadline blocks redelivery to a healthier consumer. Dead-letter forwarding requires the Pub/Sub service agent to hold Publisher on the DLQ topic, a permission grant that's easy to forget since it's on the topic, not the subscription, and the resulting failure mode (messages just vanish after maxDeliveryAttempts with no DLQ landing) has no obvious error message pointing at IAM.
An on-call engineer gets paged because order-processing-sub's unacked message count is climbing steadily with no corresponding growth in the configured dead-letter topic, even though the handler is clearly failing on a bad message repeatedly. Digging into IAM shows the DLQ topic's policy only grants Publisher to the application's own service account, not the Pub/Sub service agent that actually performs the dead-letter forward. They use the builder to confirm the deadLetterPolicy block is otherwise correct, grant roles/pubsub.publisher to service-<project-number>@gcp-sa-pubsub.iam.gserviceaccount.com on the DLQ topic, and poison messages start landing in the DLQ within the next delivery attempt cycle.
The DLQ topic needs Publisher granted to the Pub/Sub service agent, not your application's service account, this single missing binding is the most common reason a dead-letter policy silently does nothing.
enableMessageOrdering only guarantees order within a single ordering key; if you don't set an ordering key on publish (or use a constant one), ordering degenerates to no practical guarantee across the full message stream.
pushConfig with oidcToken requires the pushEndpoint to validate the token's audience matches exactly, a trailing-slash mismatch between the configured audience and the endpoint's actual URL is a common source of silent 401s that look like a networking problem.
The builder validates that name, topic, and ackDeadlineSeconds resolve, the three fields the Pub/Sub API rejects a CreateSubscription call without, and leaves the richer behavior (dead-letter, retry, ordering, push vs pull) as structurally-checked but semantically your call, since which combination is correct depends entirely on your delivery and ordering requirements.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.