Fix GCP Pub/Sub Retry Policy Errors

When working with GCP Pub/Sub, you may encounter a configuration error that prevents your data pipeline or messaging system from working. This guide explains the most common mistake with retry policy and shows the exact fix.

A Common Mistake

Not configuring a retry policy for a push subscription, causing failed deliveries to retry with default aggressive retry behavior that overloads the endpoint.

The incorrect command:

gcloud pubsub subscriptions create my-sub --topic=my-topic --push-endpoint=https://my-service.example.com/push

Error output:

Created subscription with default retry.
Default: retry immediately on failure, up to 600s total.
When the endpoint is momentarily down (unhealthy during deploy), Pub/Sub retries aggressively sending 100+ messages per second. This DDoSes the endpoint, making recovery slower.

The Correct Approach

The right way to configure retry policy in GCP Pub/Sub:

gcloud pubsub subscriptions create my-sub --topic=my-topic --push-endpoint=https://my-service.example.com/push --min-retry-delay=30 --max-retry-delay=300

Successful result:

Created subscription with custom retry.
Min retry delay: 30s.
Max retry delay: 300s.
When the endpoint is down, Pub/Sub waits 30s before first retry, then up to 300s between retries. The endpoint has time to recover. Retry budget lasts 12 days.

How to Prevent This

Configure retry delay: min 10s (default 10s), max 600s (default 600s). Set longer delays for endpoints that take time to recover. Use dead letter topics for messages that repeatedly fail. Monitor delivery attempts with subscription/num_undelivered_messages.

FAQ

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro. Secure your cloud with DodaTech.