Dead Letter Queue

When an event fails delivery after all retries, it goes to the dead-letter queue (DLQ). No data is lost — every failed event is stored with its full context for investigation and one-click retry.

How events end up in the DLQ

1. An event fails delivery to the destination (API error, timeout, validation failure)
2. PullPush retries with 10x exponential backoff (increasing delays between attempts)
3. If the circuit breaker trips (too many consecutive failures), retries pause to let the destination recover
4. After all retries are exhausted, the event moves to the DLQ

What's stored

Each DLQ entry includes:

• Full event payload — the canonical data that was being synced
• Error details — HTTP status, error message, response body
• Retry history — timestamps and results of each retry attempt
• Source context — which connection and flow produced the event

Retrying events

From the dashboard:

1. Navigate to the DLQ for your flow
2. Review failed events and their error details
3. Click Retry on individual events or Retry All for bulk
4. Events re-enter the pipeline with fresh retry counters

Clustering

When many events fail for the same reason (e.g., destination API returns 503), PullPush groups them into a cluster. You can:

• See how many events share the same error pattern
• Fix the root cause (e.g., update expired credentials)
• Retry the entire cluster at once

AI remediation

PullPush can analyze DLQ errors and suggest fixes:

• Credential issues — "API key expired, rotate in Settings"
• Schema mismatches — "Field 'variant_id' expected number, got string"
• Rate limiting — "Reduce batch size or enable rate limit config"

These suggestions appear inline with the error details.