You built the server-side integration, or paid someone to, and Events Manager still shows nothing arriving from the server. Here is where to look, the causes ranked by how often they are the answer, and how to prove an event actually landed.
Start in Events Manager, in the data sources list, and make sure you have the right dataset open. Accounts that have been through a replatform, an agency handover, or a Business Manager migration usually own more than one, and the wrong one will be empty for entirely legitimate reasons.
With the dataset open, look at the event list and the connection method shown against each event. This is the reading that matters. An event marked as browser only is not being sent from your server, whatever your integration's dashboard claims. An event showing both browser and server is arriving through both paths, and your problem is elsewhere. Then set the date range deliberately, because an integration that stopped three weeks ago still shows history.
Two more places are worth a glance before you open any code. The diagnostics tab collects Meta's complaints about your events, including malformed values and missing required fields, with the affected volume next to each. The testing tab tells you whether events are landing there instead of in the dataset proper, which is its own cause, covered below.
The most common single reason, and the one that produces the cleanest silence. Server requests authenticate with a token, and a token that has stopped working is rejected at the door with an error your application may never surface. Tokens generated from a personal login are the vulnerable kind: a password change, a removed role, or an employee leaving can invalidate them, and nothing in Ads Manager announces it.
The fix: generate a system user token in Business Settings, give that system user access to the dataset and the ad account, and use it in production. Then make one manual request and read the response body instead of assuming success. Authentication problems come back named and explicit.
Second most common, and often invisible because the integration is working perfectly. The events arrive, they are accepted, and they land in a dataset nobody is watching. This happens when a store creates a new pixel during a rebuild and the server code keeps the old ID, when a staging environment holds a different value, or when a contractor pasted an ID from another client.
The fix: compare the ID in your server configuration character by character against the ID in the Events Manager URL for the dataset you have open. If they differ, you have your answer in ten seconds. Check your browser pixel is on the same ID too, because a split across channels breaks deduplication as well as reporting, and our free Meta pixel audit lists every pixel ID it can read on your live pages.
Meta accepts the request or it does not, and rejections are specific. Four causes account for most of them.
Underrated and genuinely common. The test event code is a temporary parameter that routes events into the Test Events view while you build, and it is meant to be removed. When it ships to production, your events reach Meta as test traffic, so the dataset overview stays flat while the testing tab quietly fills. Search your codebase and tag configuration for it early, because from the outside this looks identical to sending nothing.
If your server events come from a platform integration, a server-side tag container, or a partner app rather than your own code, the connection is a piece of state that can lapse. App updates, permission changes, an unfinished reauthorization, and plan downgrades all break it. The integration's own screen sometimes still reads as connected, so verify from Meta's side: if Events Manager reports no server events, the integration is not sending them. Platform-specific setups are covered in the Shopify and WooCommerce guides.
The final cause is architectural. Tracking calls are often written as fire and forget, wrapped in a try block with an empty catch, so a failing request never reaches your logs or your error monitoring. Queued senders make it worse: the job fails, retries, fails again, and the result is a silent absence rather than an alert.
The fix: log the response body and the trace identifier Meta returns, at least for conversion events, and alert on a run of failures. An integration you cannot see the output of is one you find out about a quarter late.
Two tools, in this order. The Payload Helper lets you build and post a single event by hand against your dataset. Use it as a control: get a payload Meta accepts, then diff it against what your integration sends. Timestamp unit mismatches and missing browser context show up straight away.
Then open Test Events, copy the code it gives you, and put your integration through a real transaction with that code attached. The server event should appear within seconds with its parameters listed, and if your browser pixel covers the same action, the pair should be recognized as one rather than two. When it passes, remove the test code and confirm the next real event lands in the dataset overview.
The mistake to avoid: declaring victory on the Test Events screen. Test Events proves the path works for a request you deliberately made. The dataset overview the next day proves it works for the traffic you did not.
Sometimes nothing is broken. If the Conversions API was never actually implemented and the site runs a browser pixel alone, no server events is a description of your setup rather than a fault. Plenty of accounts run that way.
It is worth knowing what it costs you, and the tradeoff is laid out in Meta pixel vs Conversions API. The dangerous state is not browser only. It is believing you have two channels when you have one, then reading your reporting as though the coverage were complete, which is what why your ROAS numbers are wrong covers.
Server events are half the setup, and the browser half is the part an outside scan can genuinely read. Our free Meta pixel audit loads your live pages and reports which pixel IDs are present, whether the same ID is installed through more than one layer, which standard events it can find, whether your conversion calls carry the event ID keys deduplication depends on, and whether it sees any signal of a server-side pipeline. That last item is a hint rather than a verdict, so it is marked as needing verification.
It cannot see inside your dataset, since the receipt side of this problem lives in Events Manager. What it can tell you is whether the browser events your server events are meant to deduplicate against are healthy at all. The full checklist behind the scan is the Meta pixel audit guide, and if your symptom is doubled counts rather than missing ones, start with the Meta pixel firing twice.
Either nothing is being sent, or what is being sent is not landing in the dataset you are looking at. Those are the only two possibilities and they are easy to tell apart. Post one event by hand with the Payload Helper against the dataset ID you have open. If it appears, your sending code is the problem, and the usual reasons are a token that no longer works or errors your application is discarding without logging. If it does not appear, you are looking at the wrong dataset, which happens constantly in accounts that were migrated between Business Managers or that created a second pixel during a replatform.
Read the response body from a real request. An authentication failure comes back as an OAuth error rather than as silence, and the message names the problem directly. If your integration logs nothing, send one test payload from the Payload Helper or from your own terminal and look at what comes back. Tokens generated against an individual person's login are the fragile kind, because they can stop working when that person changes a password, loses a role, or leaves the business. A system user token issued in Business Settings is the durable option and it is what any production integration should be using.
No, and leaving one in is a genuine cause of the symptom on this page. The test event code is a temporary parameter that routes events into the Test Events view so you can watch them arrive while you build. Events tagged with it are treated as test traffic. If a developer hardcoded the code during setup and it shipped, your events are arriving at Meta and still will not appear in normal reporting, which looks identical to not sending them at all. Remove the parameter from production and confirm the events show up in the dataset overview rather than only in the testing tab.
It proves the shape of your payload is acceptable and that this particular request was accepted. It does not prove your application sends the same thing in production. The helper is best used as a control: build a payload that Meta accepts, then compare it field by field against what your integration actually transmits. Differences in timestamp units, hashing, or a missing action source usually become obvious immediately. Follow it with Test Events on a real transaction, because that is the check that covers your live code path rather than a hand-built request.
Not necessarily. Plenty of accounts run browser only on purpose, and if the Conversions API was never set up then zero server events is the correct reading rather than a fault to chase. The question worth asking is whether that is still the right choice for your spend, since browser events are lost to blockers, privacy defaults, and abandoned tabs, while your server knows about orders the browser never reported. What is not fine is believing the Conversions API is live when it is not, which is the state most people are in when they land on this page.
A server integration nobody has verified since the day it shipped is an assumption, not a channel. Scan the browser half of your setup in about 20 seconds, or book a call and we will open Events Manager together.