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, Google and TikTok, all three of which deliver server-side. 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 five statuses:

• Sent - the platform or tracker accepted the conversion. Done.
• Pending - queued; a worker picks it up within seconds.
• Failed - an attempt errored. CAPI gets up to 5 attempts with exponential backoff (waits of 5s, 10s, 20s and 40s, about a minute and a quarter for the whole chain); a postback gets up to 3 attempts and is done in seconds. 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.
• Suppressed - per-user dedup held the delivery back: the campaign (for CAPI) or the postback rule runs in a mode that sends one conversion per person. It's an honest terminal status, not a failure - such rows are never retried, never go dead, and never reach the problem-deliveries table.

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.

Every CAPI platform card carries one more block: Skipped (not sent). It appears as soon as the window holds at least one skip, with Today and 7d counts broken down by reason: "Platform not connected", "No CAPI account for the pixel", the click-ID row, "Click expired" and "Event not mapped". The click-ID row is titled by the platform of the card it sits on, because the identifier differs per platform: "No Google click ID (gclid)" on Google, "No TikTok click ID (ttclid)" on TikTok, and a neutral "No click ID" on a card whose platform never reports that reason at all. Those two adapters are the ones that report it - Google skips a click that carried no gclid/gbraid/wbraid, TikTok a click that carried no ttclid - while "Click expired" belongs to Google alone (a click older than 89 days, a day of slack under Google's 90-day upload retention), so on Meta's card both rows stay at zero. The third one, "Event not mapped", is shared: the dispatcher writes it whenever an event type isn't in that platform's mapping and no event name was set by hand, so on Meta's card this row can very well be non-zero. The very first row, "Platform not connected", answers the question ahead of all the others: the campaign carries no key for this platform in its integrations at all, meaning the setup was never started. That is what launching traffic before attaching the pixel looks like - clicks arrive, not one event reaches the platform, and until this counter existed those events left no trace whatsoever: no delivery row, no error, no log line. Tell it apart from the next row, where the setup was started and left unfinished, and which is fixed by reconciling ids rather than by attaching a pixel. The "No CAPI account for the pixel" row comes second for a reason: the others cut off part of the traffic, while this one means the org has no CAPI account carrying the pixel ID recorded in the campaign's integration, so not a single conversion of that campaign reaches the platform. Usually the pixel was changed in one place and left stale in the other. A non-zero value here is a reason to compare the campaign's pixel ID against the CAPI account before investigating anything else. 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 "The 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 89 days, a day of slack under its 90-day 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.