Mautic Tracking Script on My Website Stops Recording New Visits After Extended Uptime

Hello Mautic Community,

I am currently facing one persistent issue with Mautic tracking on my website, and I am hoping someone can help me identify the underlying cause. The main problem is that the Mautic tracking script initially records website visitors correctly, but after the website has been running for some time, new visitor activity suddenly stops appearing in Mautic even though the website itself continues working normally. Visitors can browse the pages, click links, and interact with the site without any visible errors, but those new visits are not consistently reflected in Mautic. What makes this particularly confusing is that the tracking works correctly immediately after deployment or after I make certain configuration changes, and then at some point the tracking appears to stop collecting new activity. Existing contacts and previously collected data remain available in Mautic; it is specifically the continued recording of new website activity that seems to stop.

I have verified that the Mautic tracking JavaScript is present on the affected website pages and that it is being loaded through the expected integration. When I inspect the page source and browser developer tools, the tracking code is still present even after the problem occurs, so it does not appear to be a simple case of the script disappearing from the website. I have also tested the affected pages in different browsers and confirmed that the website itself continues to load normally. Before the issue occurs, I can see the tracking request being generated when a visitor loads a page, and the corresponding activity becomes available in Mautic as expected. Once the problem starts, however, the website continues serving the same pages while the expected tracking activity becomes delayed or completely absent from Mautic, which makes me suspect that something is preventing the tracking request from being processed successfully.

I have also checked the browser network requests to determine whether the problem is occurring before the request leaves the visitor’s browser or after it reaches the Mautic installation. During a normal period, the tracking request is sent and receives a successful response, but during the affected period the request does not always result in a corresponding activity record. I have not found a consistent browser-side JavaScript error associated with the failure, and refreshing the page does not always immediately resolve it. Because the website is publicly accessible and visitors are using different devices and networks, I initially suspected that the issue might be related to browser caching or an individual visitor’s environment, but the behaviour appears to affect multiple visitors rather than one specific browser or machine.

The Mautic installation itself remains accessible during the incident, and I can log into the administration area and view previously collected visitor information normally. The website server also continues responding to normal HTTP requests, so there is no obvious general outage occurring when tracking stops. I have reviewed the server and application logs around the time of the missing tracking activity, but I have not yet found a clear error that explains why new tracking events are not being recorded. I am particularly interested in determining whether there is a queue, cron-related processing step, PHP process, database operation, or Mautic configuration involved in receiving and processing tracking requests that could cause new activity to stop being recorded while the rest of the installation remains operational.

I have tried restarting the relevant website services and clearing caches when the issue occurs, and tracking sometimes begins working again afterward, but I do not want to treat restarting services as the permanent solution because the problem eventually returns. I have also checked that the tracking code is consistently deployed across the pages where I expect visitor activity to be recorded. There are no intentional changes to the tracking configuration immediately before the failure, so I am trying to determine whether there is a resource or processing condition that develops gradually over time. Since the problem appears after the system has been operating normally for a while, I would especially like to know what Mautic logs, server metrics, tracking endpoints, or database information I should monitor continuously so that I can capture useful evidence at the exact moment tracking stops.

I would appreciate guidance from the Mautic community on how to systematically troubleshoot this tracking failure and determine where the tracking request is being lost or rejected. Specifically, I would like to know the recommended way to verify that the Mautic tracking endpoint is receiving requests, whether there are particular Mautic logs or cron processes that should be checked when visitor activity stops appearing, and whether there are known configuration or resource conditions that can cause tracking to stop while the main Mautic interface remains available. My goal is to identify the actual cause rather than repeatedly restarting services, and to ensure that visitor activity from my website continues being recorded reliably over long periods without unexpectedly stopping. Sorry for long post!

Is there anyone who can guide?

Hi,
are you using any kind of caching / cdn in front of your mautic?
Maybe both problems (forms and tracking) you reported may be related…

Since restarting services brings it back, I would look at resources that build up on the Mautic server rather than at the website.

1. Confirm the endpoint: every page view from mtc.js is a POST to /mtc/event on your Mautic domain. In the browser network tab during a bad period, check the status and timing of that request. A 502/504 or a request that hangs for seconds points at PHP, a 200 with no hit points at Mautic or the database.

2. PHP FPM: tracking hits are not queued and not cron driven, they are written to the page_hits table synchronously. If pm.max_children is too low, or long running requests (campaign or segment work triggered via the web, slow API calls) pile up, new hits wait or time out while the admin still feels usable. Check the FPM log for “server reached pm.max_children” and enable the FPM status page to watch active processes.

3. Mautic logs: var/logs/mautic_prod-YYYY-MM-DD.php (or app/logs on older versions). Look for Doctrine errors, deadlocks or “Lock wait timeout” around the time hits stop.

4. Database: page_hits and lead tables grow fast. Run SHOW PROCESSLIST while it is failing to see locks or slow queries, check free disk space, and make sure the cron mautic:maintenance:cleanup runs so old anonymous contacts and hits get purged.

5. Configuration: in Configuration > Tracking Settings, check the “Do not track” IP list and bot list, and if you are behind a proxy or CDN, make sure the real visitor IP is passed through, otherwise all visitors can collapse into one or be filtered out.

If you capture the FPM status and the processlist at the moment it stops, that usually tells you which of these it is.