How to know if your tracking broke after a site deploy
Deploys break tracking more than anything else. The problem is that nobody checks. Here is how to know within the first hour, and what to look at if you are finding out days later.
6 min read
Why deploys break tracking specifically
Most tracking setups are fragile in a specific way: they depend on a chain of things happening in the right order on the right page. A checkout confirmation fires a dataLayer event, which triggers a GTM tag, which calls the GA4 and Meta scripts, which send the network request before the page redirects.
Any change to that chain can break the last link. A developer updates the checkout flow and the confirmation page renders differently. A new script loads in a different order. A CSP header gets added to a payment page. None of these look like tracking changes, but all of them can silently stop your events from firing.
If you just deployed: check these now
Run through this list within the first hour of a deploy. It takes about 10 minutes and will catch the most common breaks before they affect reporting.
Open GA4 Realtime and complete a test conversion
GA4 Realtime shows events within a few seconds of firing. Open it in one browser tab, go through your full conversion flow (add to cart, checkout, confirmation) in another, and watch for the purchase or lead event to appear. If it does not show up within 30 seconds, your GA4 tracking is broken.
Where to find it: GA4 admin console, left sidebar, "Realtime"
Check the Meta Pixel Helper on your confirmation page
Install the Meta Pixel Helper Chrome extension if you do not have it. Load your order confirmation page after completing a test purchase. The extension should show a Purchase event firing. If it shows nothing, or shows the pixel loading but no event, your Meta tracking is broken.
Also check: does the pixel show as active at all? If not, the pixel script itself is not loading on that page.
Check network requests in DevTools on the confirmation page
Open DevTools (F12), go to the Network tab, and filter for these:
google-analytics.com/mp/collectfor GA4 Measurement Protocolwww.google-analytics.com/g/collectfor GA4 client-sidefacebook.com/trfor Meta Pixel
Complete a test purchase and watch for these requests. A missing request means the tag is not firing. A request with a 4xx or 5xx status means it is firing but being rejected.
Check the browser console for errors
Load your confirmation page and open the Console tab in DevTools. Look for:
- CSP violations:
Refused to load script - Script load failures:
net::ERR_BLOCKED_BY_CLIENT - JavaScript errors that might prevent your dataLayer push from executing
A deploy that adds a new CSP header is one of the most common ways tracking silently breaks on checkout pages.
Compare today's event counts to the same time yesterday
If your site has consistent enough traffic, compare the event count from the hour after the deploy to the same hour the day before. A 50%+ drop in purchase or lead events is a strong signal something broke. A smaller drop warrants a closer look.
In GA4: Reports, Engagement, Events. Filter to the past few hours and compare to the previous period.
Test on mobile, not just desktop
Responsive layout changes, mobile-specific JavaScript behavior, and touch event handling can cause tracking to break on mobile while desktop looks fine. Use Chrome's mobile emulation or test on a real device. If you use GTM, preview mode works on mobile too.
If you are finding out days later
The immediate checks above assume you are finding out within hours. If you are discovering a break days after the fact, the approach shifts to scoping the damage and identifying the exact moment it started.
Find when it broke, not just that it broke
Go to GA4, pull event counts for the past 30 days by day, and find the day the count dropped. Cross-reference that date with your deploy log. The correlation will almost always be there. This tells you exactly which deploy caused the break and how much data is affected.
Do not try to recover the lost data
GA4 and Meta do not allow retroactive event injection in a way that would restore historical accuracy. Once events are missed, they are gone from your analytics. Focus on fixing the break and documenting the gap period so future analysis accounts for it.
Audit the specific pages that changed in the deploy
Pull the diff from the deploy that coincides with the drop. Focus your audit on pages and components that changed. A break caused by a deploy is almost always localized to what was touched in that deploy.
Adjust reporting for the gap period
If your tracking was broken for 10 days, exclude that date range from trend analysis and note it in any reports shared with stakeholders. Comparing a broken-tracking week to a normal week will produce misleading conclusions.
The actual fix: stop relying on manual checks
The checklist above works, but it only works if someone runs it after every deploy. In practice, that does not happen. Developers are focused on the code change; marketing teams are not told when a deploy goes out; the checklist exists in a document nobody remembers to open.
The more durable solution is monitoring that catches the break automatically: software that knows what your events looked like before the deploy and alerts you within minutes of the first missed event after.
That is what Kickin does. It watches your GA4 and Meta events continuously, detects drops and cross-tracker gaps as they happen, and sends an alert before the break has time to corrupt a week of reporting.
Related: Tracking audit vs. tracking monitoring · Why checkout tracking is not firing · Tag monitoring