Why it happens
The pixel code is not on the page
The pixel code is not on the page
A redesign, a new theme or a new landing page builder dropped the base code. The homepage still has it; the pages that matter do not.
A consent banner holds it
Consent tools keep marketing tags back until a visitor accepts. Visitors who ignore the banner send nothing, and neither does your test if you never click accept.
A tag manager rule never triggers
In Google Tag Manager, a trigger scoped to the wrong pages, a paused tag or a container that was never published looks exactly like a missing pixel.
The page fires a different pixel ID
Code copied from an old account, an agency or a template fires happily and reports to a dataset you never open. Two pixels on one ad account make this easy to miss.
Blockers and browser privacy
Ad blockers and strict browsers stop the pixel for some visitors. That is normal loss, and the reason to run the Conversions API beside it. A pixel that fires for nobody is a broken install.
How to fix it, step by step
Read the last activity
In Events Manager, open Data sources, select your dataset and read the Overview tab. Each event shows when it was last received and whether it came from Browser, Server or both.
Watch the request
Open the page in a private window with blockers off. Open dev tools, go to Network, filter for facebook.com/tr and reload. Accept the cookie banner. A request carrying your pixel ID means it fired.
Match the pixel ID
View the page source and find the fbq init call. The number in it must match the dataset ID shown in Events Manager.
Check consent and the tag manager
If the request appears only after you accept cookies, the banner is the block. In Google Tag Manager, confirm the trigger covers every page you need and the container is published.
Confirm in Test events
In Events Manager, open Test events, enter your URL and browse the site. Events show up within seconds when the pixel fires.
Read Diagnostics
The Diagnostics tab lists what Meta itself sees going wrong with the dataset, with the affected events.
Steps checked against Meta Business Help Center articles: Troubleshoot your Meta Pixel; About Meta Pixel; Test your events in Events Manager; About diagnostics in Events Manager.
Sprites diagnoses this
Sprites diagnoses it
Sprites reads your pixel and CAPI health and shows where it breaks: which events stopped, from which side, and when Meta last received them.
What Sprites does
- Reads the last time Meta received anything from each pixel connected to the ad account.
- Counts every event over the last 7 and 28 days, split into browser pixel and Conversions API, so a page-side break stands apart from a server-side one.
- Flags any event that arrived the week before and not at all this week.
- Reads Meta's own diagnostics for the dataset and puts every failed check in plain words.
What it doesn't do
- Install or edit the pixel code on your site
- Load your pages in a browser to watch the request
- Send events to the Conversions API
Questions
How do I know if my Meta pixel is firing?
Load the page with the Network tab open and filter for facebook.com/tr. A request means it fired. Events Manager confirms Meta received it, under Data sources, your dataset, Overview.
Pixel Helper shows the pixel but Events Manager shows nothing. Why?
The page is almost always firing a different pixel ID than the dataset you opened. Match the ID in the page source with the dataset ID.
How long until events show in Events Manager?
Test events shows them within seconds. The Overview graph can lag by up to about 20 minutes.
Do my ads stop if the pixel stops firing?
No. Spend continues. Reported conversions fall and ad sets optimizing for that event lose the signal they learn from.
Does an ad blocker break the pixel?
For that visitor, yes. Pair the pixel with the Conversions API so those conversions still reach Meta from your server.
See where it breaks
Connect your accounts. Sprites reads them side by side and shows you exactly where the numbers split.