Delivery Health: make sure every conversion reaches the ad platforms and your tracker

You already paid for the click. If the deposit it produced never reaches Meta or Google, the platform's optimizer keeps buying lookalikes of people who don't convert. If the S2S postback to your affiliate tracker fails, the conversion doesn't exist in your own accounting either. The Delivery Health page is the one screen that answers "did every conversion actually arrive": per-platform CAPI cards, per-rule postback cards, a table of everything stuck, and a Re-fire button for manual recovery.

Reading the cards

The top of the page shows one card per CAPI platform, Meta and Google today, since TikTok server-side delivery is still coming soon and never produces a card. Below those sit one card per postback rule that had at least one delivery in the last 7 days. A CAPI platform can also show a card with zero deliveries if it skipped conversions in that window instead of sending them, which is exactly the case the Skipped block below is for.

Each card counts deliveries in two windows, 24h and 7d, across four statuses:

• Sent - the platform or tracker accepted the conversion. Done.
• Pending - queued; a worker picks it up within seconds.
• Failed - an attempt errored. CAPI retries up to 5 times with exponential backoff (5s, 10s, 20s, 40s, 80s, roughly two and a half minutes end to end); postbacks retry up to 3 times over well under a minute. A failed row often converges to Sent on its own inside that window. Once the last attempt fails, the row flips to Dead automatically, no cron job or manual step needed.
• Dead - every automatic retry was exhausted. Nothing more happens without you.

The badge is a traffic light: Healthy with zero problems, Failures (yellow) when something failed, Dead letters (red) when at least one delivery died. Each card also surfaces the last error text with a timestamp, usually enough to spot an expired token without opening logs.

Google's card carries one more block: Skipped (not sent), with Today and 7d counts broken down by reason - no Google click ID (gclid missing), click expired (past Google's 90-day upload retention), or event not mapped. A skip is a deliberate no-send, not a failure: it never writes a delivery row and never shows up in the failed or dead counts, or in the table below. That's the direct answer when a mixed Meta-and-Google campaign shows Google converting far less than Meta - check this block before assuming something is broken.

The problem-deliveries table

Below the cards sits a paginated table of failed and dead rows only, with two tabs: CAPI and Postbacks. The CAPI tab shows platform, event ID, status, attempt count, the error and creation time. The Postbacks tab adds the HTTP method and the status code your tracker's endpoint returned. A 500 from the tracker and a network timeout debug very differently.

Re-fire: what it actually does

1. Fix the root cause first: refresh the Meta access token, restore the Google service-account access, re-enable the postback rule.
2. Click Re-fire on the row. The button flips to Queued. A fresh delivery attempt goes through the normal queue with the full retry chain and the same payload.
3. Delivery is asynchronous. Reload a minute later; a successful re-fire moves the row to Sent and it leaves the problem list.

Re-fire refuses honestly instead of pretending. Only failed and dead rows can be re-fired. If you removed the pixel from the campaign or deleted the CAPI account, you get "Platform is no longer configured on the campaign." Queueing it anyway would just produce another dead row. "The event is not billable" means billing blocked the event; top up on Billing first. Postback re-fires are refused the same way when the rule was deleted or disabled, so a manual re-send can't quietly bypass a rule you turned off.

Double-counting protection: a postback re-fire reuses the original fire ID, so if the first attempt actually reached your tracker, the repeat is suppressed before the HTTP call. CAPI re-fires lean on the platform's own event-ID dedup instead: Meta's window is roughly 48 hours, so re-firing much older rows can double-count conversions in Ads Manager.

When to worry - and when not

• Worry when Dead is above zero, or the same last error keeps repeating: expired access token, revoked service-account access, a wrong dataset or conversion action ID.
• Don't worry when Google shows fewer conversions than Meta on mixed traffic. A Meta-originated conversion has no gclid, so Google skips it on purpose instead of failing - check the Skipped block on Google's card for the exact reason and count. Google also skips clicks older than 90 days, past its upload retention.

Common pitfalls

• Re-firing without fixing the cause just mints new dead rows. The button re-sends, it doesn't repair configuration.
• Meta rows older than about 48 hours are risky to re-fire: vendor dedup no longer covers them.
• A paused workspace blocks events at billing, so their deliveries are refused as not billable. Check the balance before blaming the integration.
• A Google card sitting at zero deliveries on Meta-heavy traffic is expected, not broken. Its Skipped block explains why.
• TikTok never gets a card. Server-side delivery for it isn't live yet, so seeing nothing there isn't a misconfiguration.