How to tell if your Meta pixel stopped firing

The five-minute check

1. Go to Events Manager → Data sources and open your pixel. The overview graph shows events per day. Set it to the last 28 days.
2. Look at Purchase specifically, not “all events”. PageView often keeps firing from a cached header while the checkout events die, which is why the overview looks healthy.
3. Open WooCommerce → Analytics → Orders (or your order list) for the same 28 days. Write the two daily series next to each other. You are not looking for a match; you are looking for a change in the ratio. A pixel that was reporting 70 percent of orders and now reports 5 percent has stopped. One that has always reported 70 percent is a consent and blocker gap, not a failure.
4. Note the date the ratio fell. Keep it; it is your main clue.

If the ratio is steady, your pixel is fine and you can stop here, although the tripwire section at the end still applies.

Confirm it on your own thank-you page

The Events Manager graph lags by hours and hides partial failures. Confirm with a live walk:

1. Install the Meta Pixel Helper extension in Chrome. Open your store. The icon turns blue and shows the number of pixels found and which events fired. You want exactly one pixel ID, the one in Events Manager, and a PageView.
2. Add a product to the cart. The helper should show AddToCart with a value and currency. Go to checkout: InitiateCheckout.
3. Place a real test order (a 100 percent coupon on a cheap product is fine) and land on the order-received page. You want Purchase with the order total, currency, and an event_id or order_id parameter.
4. In Events Manager → Test events, enter your store’s URL and repeat the walk. Each event should appear within seconds, labelled “Browser” and, if you have the Conversions API, a second copy labelled “Server” with the same event ID and a “Deduplicated” tag.

What you see here is the diagnosis. No pixel at all: the code is gone. Pixel but no Purchase: the thank-you page is not firing it. Purchase without a value: the data layer broke. Two pixel IDs: a duplicate install, which is a different problem (your numbers go up, not down). Browser event present, server event missing: the Conversions API broke, not the pixel.

The four usual causes

1. A theme or plugin update

Most pixels on WordPress are injected by a plugin (Meta’s own, PixelYourSite, a tracking suite) or pasted into a theme file. A theme update overwrites header.php. A plugin update changes a hook. A caching plugin starts minifying the script and breaks it. Check the date you noted against Dashboard → Updates history or your host’s activity log. If an update landed within a day of the drop, you have found it.

2. A consent banner change

If you added or reconfigured a cookie banner, the pixel may now be blocked until consent, and a large share of visitors never consent. That is not a failure, but it looks like one. Check whether the banner is set to block “marketing” scripts and whether Meta is categorised there. Test as a visitor who declines and one who accepts; the Pixel Helper should show the difference.

3. A checkout change

Switching from the classic checkout to the block checkout, adding an express payment button, moving to a new payment gateway, or changing the order-received URL all change where and when the purchase fires. Offsite gateways are the common break: the customer pays on PayPal and never returns to the page that holds the pixel. Check the misses by payment method; if one gateway is missing almost entirely, this is your cause.

4. A blocked domain or ad-blocker drift

Meta’s script loads from connect.facebook.net. Corporate networks, some DNS filters and most ad blockers stop it. This does not break overnight for everyone, but it does drift: a browser update that enables stricter tracking protection by default can take 10 to 15 percent of your events in a week. If no update, banner change or checkout change explains the date, and the drop is gradual rather than a step, this is it, and the answer is the Conversions API, not fixing the pixel.

Is it the pixel, or the Conversions API?

If you run both, Events Manager shows an Event Match Quality score and a browser/server breakdown per event. Three patterns:

• Browser down, server fine: the page-side code broke. Ads keep optimising on server events; fix the pixel at leisure, but do fix it, because the browser event carries the click ID that server events often lack.
• Server down, browser fine: an access token expired or a plugin update broke the API call. Ads lose every order from consent-declined and blocked browsers immediately. Regenerate the token in Events Manager → Settings and re-test.
• Both down on the same day: the shared source broke, which is almost always the order-received page itself or the plugin that feeds both.

Fix it

1. Re-add the base code through one method only. If a plugin manages the pixel, remove the pasted copy from the theme. One pixel ID, one place.
2. If a theme update wiped a pasted snippet, move it out of the theme for good: a plugin, GTM, or a child theme that updates do not touch.
3. Make Purchase fire on the order itself, not only on the page: enable the Conversions API in your pixel plugin with the same event_id on both sides so they dedupe.
4. If the banner was the cause, configure Meta as a “marketing” vendor and send the Limited Data Use flag for declined visitors rather than dropping the event entirely.
5. Re-run the thank-you page walk and the Test Events check. Then watch the daily ratio for three days.

How to tell it worked

The Purchase line in Events Manager returns to its previous ratio against orders within 48 hours, Test Events shows browser and server copies deduplicated, and the Pixel Helper on the order-received page shows a single pixel with a value. Event Match Quality for Purchase should sit at “Good” or above once server events carry email and phone hashes.

Set a tripwire so you hear about the next one

Every dead pixel in this article was found weeks late, by someone noticing the ad account’s cost per purchase had doubled. The campaign kept spending; Meta just stopped being told what worked. The fix for that is a daily comparison of Purchase events against WooCommerce orders with an alarm when the ratio moves, which is what TagEasy does for Meta, GA4, Google Ads and TikTok at once: a baseline for every event on your site, a scripted checkout walk that catches a dead thank-you page before a customer does, and an alert in Slack or email the day anything stops firing. The free tier covers one site and does not ask for a card.