Meta Pixel not firing: how to find out why
Updated 2026-10-09
A Meta Pixel event is a request from the page to facebook.com/tr/, with the pixel ID in id and the event name in ev. If no such request leaves the page, the pixel did not fire. If it leaves the page but the event is missing or wrong in Events Manager, look at what the request carried. Work through the checks below in order: most problems show up in the first three.
What a Meta Pixel event looks like
The Meta Pixel script (fbevents.js from connect.facebook.net) sends each event as a request to /tr/. These are the keys that matter when debugging:
| Key | What it holds | Example |
|---|---|---|
id | The pixel the event goes to | 1234567890 |
ev | The event name, exactly as the site sent it | Purchase |
cd[value] | The event value | 79.00 |
cd[currency] | The currency of that value | USD |
cd[order_id] | The order ID, if the site sends one | 1001 |
eid | The event ID used to deduplicate against the Conversions API | ord-1001 |
fbp / fbc | Meta's browser ID and click ID | fb.1.17905… |
The checklist
- The script never loaded. No
fbevents.json the page means no events at all. Check that the pixel is installed on this page and in this theme or template, and that a tag manager trigger actually fires here. - The site is waiting for consent. Meta's consent API pauses sending: after
fbq('consent', 'revoke'), the pixel stops sending until the page callsfbq('consent', 'grant'). Accept the consent banner and check again before concluding the pixel is broken. - A browser extension blocked it. Ad blockers and privacy extensions stop either the script or the
/tr/request. Chrome then reports the request as failed withnet::ERR_BLOCKED_BY_CLIENT. Test in a Chrome profile without blockers, or pause them for the site. - The page moved on before the request finished. Chrome can cancel a request when the page reloads or navigates away, and reports
net::ERR_ABORTED. On the websites we checked, every cancelled analytics hit had been sent less than a tenth of a second before a reload. Events fired by a button that also navigates away are the usual suspects. - It went to a different pixel. Compare
idwith the pixel in Events Manager. Many sites run several pixels: in our study of 38 websites, 4 of 34 sent events to more than one Meta pixel, and an old or agency pixel can receive the event while yours does not. - The event name is not the one you expect. Meta's standard events have fixed names such as
Purchase,AddToCartandViewContent; any other name is a custom event. Readevexactly as sent rather than trusting the tag's settings. - The purchase is missing its value or currency. Meta's reference lists
valueandcurrencyas required forPurchase. Check thatcd[value]andcd[currency]are both in the request, and that the value is the number you expect. - It is a server-side event. Events sent through the Conversions API never pass through the browser, so they can't be seen here. If you send the same event from both, Meta recommends passing the same event ID from the browser (the
eidkey) so the two can be deduplicated.
A request that left the browser shows that the pixel fired. It does not show that Meta accepted, attributed or reported the event; that part is only visible in Events Manager.
How to check it with Pixel Debugger
- Open your site in Chrome and click the Pixel Debugger icon. The side panel opens next to the page.
- Do what should trigger the event: view a product, add to cart, complete a test order.
- In Events, look for the Meta row with the name you expect. Open it to see the pixel ID, value, currency and order ID, each with the key it came from.
- Nothing there? Open Setup: it shows separately whether the Meta Pixel script was found, whether it sent requests and whether they carried events. Requests lists failed and blocked requests with Chrome's error.
Apps that install pixels inside a sandboxed frame, such as some store platform integrations, still send ordinary network requests from the tab, so their events appear in the same list.
If the request is there but Events Manager shows nothing
- Check that
idis the pixel you are looking at in Events Manager. - Look for the event under its exact sent name, including custom names.
- If you also use the Conversions API, check that both sides send the same event ID, so the browser event isn't dropped as a duplicate of a server event you expect to see.
Related: Meta Pixel parameters, why Meta and GA4 report different revenue and duplicate purchase events.