Meta Pixel not firing? The 6 real causes, in the order to check them

Rytis Balys — Mon, 06 Jul 2026 22:15:34 +0000

"The Meta Pixel isn't firing" is one of the most common things I get called in to fix. The frustrating part is that "the pixel is installed" and "the pixel is firing" are completely different claims - and most dashboards happily say connected while the events never actually leave the browser.

Here are the six causes I check, in order, each with a verification step you can run in a couple of minutes.

First, know what you're looking for. A firing pixel sends network requests to facebook.com/tr. Open DevTools > Network, filter by tr, and act on the site. No requests = not firing, whatever your tag manager says.

1. Consent banner is blocking it (the #1 cause in the EU)

If you run Cookiebot, OneTrust or any CMP in opt-in mode, the pixel is legally supposed to stay silent until the visitor accepts. The bug: after acceptance it often stays silent, because the pixel tag in GTM isn't wired to the consent state, or fires before consent updates.

Verify: open the site in incognito, accept all cookies, then watch for facebook.com/tr requests. Silent even after full acceptance = your consent wiring is broken, not working.

2. Pixel initialized twice (or three times)

A hardcoded base code in the theme and a GTM tag and a platform integration all loading the same pixel. The symptom is usually the opposite of silence - events fire 2-3x per action, purchases double-count, and audiences get polluted. The classic version I keep running into: the base pixel hardcoded in the theme, a second copy bolted on through GTM "for safety", and the app's own integration on top - three Purchase events per order, a ROAS that looks incredible, and ad budget getting scaled on a number that's pure fiction.

Verify: in the console run fbq.getState().pixels (or use Meta Pixel Helper). More than one init of the same ID, or multiple IDs you don't recognise = consolidate before anything else.

3. GTM trigger chain never completes

The tag exists, but its trigger waits for a dataLayer event (purchase, add_to_cart) that the site never pushes - a theme update or checkout change silently broke the push. The tag is "active" and fires exactly never.

Verify: GTM Preview mode, perform the action, watch the event stream. If your trigger event never appears in the left column, the dataLayer push is gone.

4. Redirect checkouts eat the Purchase event

PayPal, financing providers, bank-redirect payments: the buyer leaves your site to pay and often never returns to the thank-you page where the Purchase pixel lives. The pixel works perfectly - for the customers who come back. The rest vanish.

Verify: compare pixel Purchase counts against real backend orders by payment method. If card orders track and redirect-payment orders don't, this is your gap. The durable fix is server-side (Conversions API from the order event, not the browser).

5. Checkout runs in an iframe or on another domain

Embedded checkouts (Eventbrite, Calendly, some booking and payment widgets) run in a cross-origin iframe. Your page's pixel physically cannot see events inside it.

Verify: if the confirmation step's URL bar or frame ancestry is another domain, stop debugging your pixel. You need the vendor's own tracking hooks, a postMessage bridge, or server-side events.

6. Ad blockers and browser privacy (the loss you can't fix client-side)

Some meaningful share of your visitors block facebook.com/tr outright - ad blockers, Safari ITP, strict browser modes. No client-side fix exists. This is exactly what the Conversions API is for: the same event, sent server-to-server, deduplicated against the browser event via a shared event_id.

Verify: in Events Manager, check the ratio of browser vs server events per event type. Browser-only setup = you're losing whatever your audience's blocker rate is, silently.

The one-line rule

Don't trust any dashboard that says "connected". Trace one real event end to end - browser network tab, GTM Preview, Events Manager Test Events - and compare monthly totals against your backend's paid orders. The number that matches reality is your backend; everything else is a suspect until proven otherwise.

This first appeared on rytisbalys.com, where I keep the rest of my troubleshooting guides - written from real audits, not documentation.

DEV Community: Rytis Balys