Most ecommerce operators find out their site has a problem when a customer tells them. I have spent more than a decade running MageCloud on the opposite assumption. By the time a customer notices that checkout is broken or that the homepage is redirecting somewhere it should not, the damage to that day’s revenue is already done. The only reliable way to know first is to have a daily monitoring stack reading every layer of the site for you while you sleep.
The reason this is on my mind today is that around 110,000 sites were compromised overnight by a supply chain attack. A popular open-source library used in many ecommerce projects was handed over to a new maintainer in China, who pushed code that started compromising every site that pulled it in. The number is likely to grow as more security teams finish their scans this week. If a developer half a world away can quietly take over a library in your stack overnight, the question is not whether your site will eventually have a problem. The question is how quickly you find out.
MageCloud Monitoring Note
The Daily Monitoring Stack We Run on Every Customer Site
ALERT INBOX
[email protected]
Every tool pushes here. Read before anything else.
SECURITY
Sansec + native Magento patches
Daily scan. 20% off with code MAGECLOUD.
UPTIME + RESOURCES
Uptime Robot + host-level dashboard
CPU, disk, memory, response time.
CODE + UX
auditIQ (testing) + Microsoft Clarity (free)
Logged errors and behaviour anomalies.
Paul Ryazanov · MageCloud · 50+ specialists across UK, Denmark, and Ukraine · 200+ scan emails read every morning
Why the First Move Is a Dedicated Notifications Inbox
Before any of these tools matter, you need somewhere for the alerts to land. We set up [email protected] on every site we manage. Every monitoring tool pushes its alerts to that inbox: every uptime check, every security scan summary, every server warning. If those alerts go to a real person’s working inbox, they get buried under client email and Slack pings and the one that mattered gets missed.
A dedicated address gives you somewhere to triage on a schedule, and it makes it trivial to share access with a developer or contractor when something needs urgent eyes. I have written before about why I still use personal Gmail to run a 30-person ecommerce agency, and the same principle applies in reverse for system alerts. Personal email is for people. System email is for machines. They are not the same inbox.
The Five Tools I Run on Every Ecommerce Site We Manage
When I open up a new customer site, these five tools go in before anything else. Each one costs little or nothing, and each one surfaces a different layer of risk.
Uptime Robot for Continuous Uptime Monitoring
Uptime Robot (uptimerobot.com) is the simplest tool on this list and the one I would not run an ecommerce business without. It is free to start, takes about five minutes to set up, and it notifies you the moment your site stops responding.
The reason this is on every site we touch is that it timestamps exactly when the site went down, which is the most useful information you can hand to your hosting provider when you ask them to check the logs. Asking a host “was there an issue this morning” almost always returns a vague answer. Asking them “what happened at 09:14 GMT today” gets the actual root cause back within minutes.
Sansec for Magento and Adobe Commerce Security Scanning
Sansec (sansec.io) is the security scanner we run on every Magento and Adobe Commerce site we host. The monthly cost varies based on the project, and they offer a free initial scan plus a trial, so you can see what they catch on your own site before you commit. Sansec also offers a 20 percent discount with the code MAGECLOUD.
If you are still trying to decide whether your current platform is the right one for security and scale, the answer is usually deeper than the platform itself. I covered the same idea from a different angle in what a failed WooCommerce to Shopify migration teaches about SEO and site security. The platform is only one variable in your risk profile, and what you bolt on around it matters more than most operators realise.
Resource Monitoring for Server-Level Surprises
Every site we run has resource monitoring on the underlying server: CPU usage, memory, disk space. Most managed Magento, Shopify, and WordPress hosts ship a built-in dashboard for this, and self-managed servers usually need a lightweight agent installed.
The warning signs of an ecommerce problem are almost always resource-shaped before they become customer-facing. A CPU spike to 80 percent for an hour is something I want to see in the morning inbox, not at 5pm when checkout starts timing out. A disk filling to 95 percent is something I want flagged a week in advance, not at the moment a single product image upload takes the entire store offline.
auditIQ for Code and Infrastructure Error Visibility
auditIQ is the newer tool in our stack. We are still testing it across a sample of customer sites, and the early read is positive. It watches the infrastructure and the codebase together, and surfaces application errors that get logged but never make it to a human. A lot of ecommerce stores accumulate hundreds of these every day and nobody ever sees them.
I am not ready to say it replaces anything in our existing stack. I am ready to say it catches things the other four tools do not. The principle matters more than this specific tool: every six to twelve months I look at one new monitoring option and decide whether to add it or swap something out. Stagnant monitoring stacks miss new attack patterns.
Microsoft Clarity for UX and Performance Anomalies
Microsoft Clarity (clarity.microsoft.com) is free, and most ecommerce operators I talk to know it only as a heatmapping tool. It is more than that. Clarity will tell you when something on your site is suddenly being clicked at twice the normal rate, when a form is being abandoned more often than yesterday, or when a JavaScript error is silently breaking part of the checkout for a slice of users. The free price tag is not a reason to be sceptical of the tool. It is a reason to install it today and let it run.
The Trade-Off I Will Admit To
This stack is not free time. The first install is one or two afternoons of work, and the daily read is real attention. For a small store with low traffic, the alert inbox is overkill, and I would not push it on a founder who is still trying to prove out the first version of a product.
What I would push it on is any ecommerce business where downtime costs money or a quiet compromise of the payment page could end the quarter. That covers a much wider band of operators than most realise. The cost of skipping the morning read is hidden until the day a customer emails to report a problem I should have caught hours earlier, and that is the day the maths flips.
Why I Do Not Want Clients Telling Me Something Broke
The reason I run all of this is not because monitoring is fun. It is because the alternative is a client emailing to say their site is down, and that email always arrives at the worst possible time. I would rather get a notification at 06:30 GMT, deal with it before any of my customers wake up, and have a clean explanation ready when they ask.
That is the operational standard every serious ecommerce business should hold itself to, and it is the same instinct behind why fixing Google Search Console issues is the fastest way to boost an ecommerce store. The tools change over time. The principle does not. Run something that watches every layer of your stack, send the alerts to a dedicated inbox, and read them before anything else.
Today’s 110,000-site attack will be next month’s old news. The only operators who saw it coming were the ones who already had this kind of stack in place.
Where to Find Me Next
If you want to compare monitoring stacks or talk through what you are already running, come find me at the next Ecommerce Camp UK. The room is full of operators who have built their own version of this, and these are exactly the conversations that fill the marketplace room.
Related reading: How I Spotted a Fake Shopify Takedown Email — what to do when a fake takedown notice impersonating Shopify lands in a merchant’s inbox, and the two tells that gave the scam away.
Related reading: Why I Refuse to Pay Hosting Two Months Ahead — the upstream vendor-billing habit that makes the monitoring layer cheaper to keep running.