Dead-letter queues and delivery monitoring for conversion APIs
CAPI endpoints return 429s, 500s, and invalid payload errors. Without retries and a dead-letter queue, failed conversions vanish. Here is what to monitor and how to alert on delivery health.
- DLQ
- retries
- observability
- CAPI
Problem: Meta CAPI returned 503 errors for two hours during a platform outage. Your webhook handler logged the error and moved on. Those purchases never reached the ad platform and nobody noticed until ROAS dropped a week later.
Why conversions fail silently
Ad platform APIs are not always available. Meta, Google, and TikTok have rate limits, maintenance windows, and intermittent 5xx responses. Payload validation errors — wrong hash format, missing required field — return 400 with a body engineers rarely read in production.
A fire-and-forget fetch() in a webhook handler loses the event permanently on failure. There is no built-in retry in your HTTP client unless you add one.
Retry with backoff
Transient failures (429, 502, 503) should retry with exponential backoff and jitter. Cap retries at 24–72 hours for conversion events — late attribution beats no attribution for ad optimization.
Permanent failures (400 invalid payload, 401 bad token) should not retry blindly. Route them to a dead-letter queue (DLQ) for inspection.
What a DLQ gives you
A DLQ stores failed events with the original payload, error response, attempt count, and timestamp. Engineers inspect why Meta rejected an event, fix credential or mapping issues, and replay without asking the user to convert again.
For high-volume apps, DLQ depth is an alert metric. A spike means something systemic broke — rotated API token, changed conversion action ID, platform outage.
Monitoring checklist
Track success rate by platform and event type over rolling 1h and 24h windows. Alert when success rate drops below baseline — not just on zero traffic.
Monitor p95 delivery latency. Log HTTP status codes and redacted response bodies for failed requests.
Review DLQ depth weekly even if alerts are quiet. Payload drift from app changes causes slow 400 accumulations.
TrackStack delivery logs
The dashboard Logs view shows per-event HTTP results across destinations. Filter by platform, status, and canonical event name during deploys.
Pair logs with Configure checklist items — missing conversion action IDs show up as 400s before you scale spend.
Sources
Official documentation and references cited in this article.
More in Engineering
First-party conversion tracking vs third-party pixels
Browser pixels and server-side CAPI solve different problems. Here is when to use each, how they complement each other, and what breaks when you rely on scripts alone.
Read postEvent deduplication between client and server
Sending the same conversion from browser and server without a shared event ID double-counts in ad platforms. Here is how dedup works at Meta, Google, and TikTok — and how to implement it in your app.
Read postWhy ad blockers break third-party pixels
uBlock Origin and filter lists like EasyList block requests to `facebook.net` and `google-analytics.com` by default. Understand the mechanism so you can design tracking that actually delivers.
Read postReady to fix your conversion pipeline?
Install the TrackStack SDK, route events to Meta and Google, and verify delivery from one dashboard.