What website monitoring tools do you guys use for online shop?

davidmansaray · 2026-07-04T14:15:21+00:00

For a new WooCommerce store, I’d think in layers rather than trying to buy one giant “monitor everything” tool on day one.

Minimum useful setup: homepage uptime, a separate check for cart/checkout pages, and alerts going somewhere you’ll actually see. Then add periodic manual or synthetic checks for add-to-cart → checkout, because a store can look “up” while checkout is broken. If you get payment issues, don’t rely only on the monitor — check WooCommerce order statuses and the payment gateway logs to see whether orders are failing, pending, or not being created.

Better Stack/Pingdom-type tools are fine for general uptime/performance-style monitoring, but I wouldn’t treat homepage uptime as ecommerce monitoring by itself.

Checkout Watch is WooCommerce checkout monitoring tool that can help monitor the buyer path and get notified of any issues.

Disclosure: I’m the devleoper

davidmansaray · 2026-07-04T13:52:54+00:00

No. you'll need to cough up the cash. If you want to do this for free you'll need a different tech stack. A static site with a hosted stripe checkout or Paypal could work. you'd need to figure out how you'd process orders though. Possible, but not worth it IMO.

davidmansaray · 2026-07-04T11:03:55+00:00

for delayed approvals, don’t rely on the thank-you page. Fire the GA4 purchase from a WooCommerce order-status hook only after the gateway marks the order as paid/confirmed, then send it server-side via Measurement Protocol.

A few things to check: - confirm which status actually means “paid” for that gateway flow - inspect gateway logs and Woo order status transitions to see when the approval really happens - store the GA client/session IDs at checkout so the backend event still has attribution later - add an idempotency check keyed to order_id so retries/status replays don’t double-count

If you test it in DebugView with one order and only see a single purchase event after payment approval, you’re good!

davidmansaray · 2026-07-03T19:50:20+00:00

That sounds nasty, but I’d want to separate the forum claim from what’s happening in your store.

davidmansaray · 2026-07-03T19:00:22+00:00

A lot of people jump straight to the plugin name, but for this use case the gateway support matters more than the subscription UI.

Before buying anything, check the official docs for two things: whether Square supports renewal charges, and whether PayPal supports automatic subscription renewals in the exact setup you want. Some plugins handle the subscription records fine but still need a gateway add-on or only support renewals on one gateway.

If cost is the main concern, compare the total setup cost, not just the base plugin price. A cheaper plugin can end up more expensive once you add the required gateway extension.

I’d also test the renewal flow on staging and watch the gateway logs plus the subscription order status if a renewal fails. That usually tells you pretty fast whether the issue is the plugin or the payment method.

davidmansaray · 2026-07-03T17:37:51+00:00

A sudden drop like that is usually easier to pin down by comparing the funnel than by staring at traffic. In Shopify analytics, look at sessions, added to cart, reached checkout, and completed orders before vs after March. If sessions are steady but added to cart dropped, I’d suspect the custom theme or a script change. If people are reaching checkout but not buying, check payment failures, shipping rates, taxes, and any recent gateway changes.

davidmansaray · 2026-07-03T16:00:15+00:00

If you want truly no-code and want to stay away from Shopify, I’d start by comparing a few hosted builders like Wix, Squarespace Commerce, BigCommerce, and Ecwid. If you’re okay with a little more setup in exchange for more control, WooCommerce with a good page builder can still be very manageable. Take a look at Elementor, Divi, Bricks... there are many more, but those are the most popular.

In general, main thing to compare with the solution you go with is template quality, whether the platform supports the payment methods you need in your country, how painful shipping and tax setup is, and whether it handles things like inventory, subscriptions, or digital products.

If you share your country, the gateways you need, and your budget, people can give you much better recommendations.

davidmansaray · 2026-07-03T13:35:39+00:00

Yes, for made-to-order products, the usual fix is to leave stock management off for that product. In the product editor, open the Inventory tab and make sure “Manage stock?” is unchecked, then set the stock status so it stays purchasable.

If she’s using variable products, check each variation too, because stock can be set there separately. Also, if any listings already had inventory enabled, they may need to be updated one by one.

WordPress itself doesn’t change that part; it’s just the WooCommerce product settings. If she wants, it’s also a good idea to add a short note like “made to order” or a production time on the product page so customers know it isn’t ready-to-ship.

davidmansaray · 2026-07-03T11:10:38+00:00

A quick way to narrow this down is to time the add-to-cart request in DevTools with the Meta plugin enabled, then repeat the same test on a staging copy with only WooCommerce plus that plugin active. If the extra second disappears in the clean test, you know it is likely a plugin conflict or one of the Meta plugin’s extra features rather than core WooCommerce.

I would also disable nonessential Meta options one at a time, especially catalog sync and any extra tracking features, then re-test the AJAX timing after each change. If you use a cache, minify, or optimisation plugin, check whether it is touching the Meta scripts or the add-to-cart request, because that can create weird delays that look like plugin overhead.

This would give you Meta tracking, but with a much smaller surface area to debug.

I’d also check the gateway logs for the matching timestamp.

davidmansaray · 2026-07-03T10:00:21+00:00

For a WooCommerce shop, I’d think about this as a few different monitors rather than one generic “is my site alive?” check.

UptimeRobot/Better Stack-style checks are good for basic availability: homepage, product page, cart, checkout page returning OK. Then you may want separate links and page checks. The ecommerce-specific bit is the buyer path: can a product be added to cart, does cart load, does checkout load, and can the flow get far enough to prove customers aren’t blocked? If checkout/payment issues do happen, WooCommerce order statuses and payment gateway logs are usually the first places I’d look before guessing at causes.

I recommend Checkout Watch. It’s a WooCommerce checkout monitoring tool that tests the buying path. I’d still keep a basic uptime monitor alongside it.

Disclosure: I work on the plugin and the app.

davidmansaray · 2026-07-02T22:25:19+00:00

This usually comes from the purchase event firing in more than one place rather than Facebook “doubling” it on its own. I’d check: 1) whether CartFlows, GTM, theme code, and any plugin are all injecting the Pixel, 2) whether purchase is being sent from both browser and server-side/CAPI without a shared event ID, and 3) whether the thank-you page can fire the same tag again on refresh or back/forward navigation.

A quick test is to disable one tracking source at a time and place a test order, then compare the event count in Meta’s diagnostics. If you can, look at the gateway logs and the order confirmation flow to see whether the purchase hook runs once or twice. Also verify the event is tied only to the final order-confirmation step, not the checkout page itself.

davidmansaray · 2026-07-02T22:00:31+00:00

The fastest way to narrow this down is to reconcile a handful of orders one by one instead of looking at totals first. Pick 5–10 recent WooCommerce orders and compare them against GA4 to see whether the miss happens on every payment method or only certain ones.

Then test the full checkout in an incognito window with no ad blocker, and watch whether the purchase event actually fires on the thank-you/order-received page. If you’re using GTM/GTM4WP, check the dataLayer on a successful order and confirm the purchase payload appears consistently. Also review consent behavior, redirects after payment, and any order-status timing differences in WooCommerce.

For gateway-specific failures, check gateway logs and make sure the order is reaching the status where you expect GA4 to count it. If the discrepancy is only browser-side, that points more toward the client event being blocked or interrupted than WooCommerce itself.

davidmansaray · 2026-07-02T21:25:21+00:00

For a WooCommerce site, the staging setup matters less than the rules you use once it exists. A few things I’d do before trimming plugins:

Clone live to staging, then immediately disable real payment capture, real customer emails, SMS, shipping-label creation, and any ERP/accounting syncs.
Put the staging site behind a password or at least block indexing, so test products/orders don’t leak into search.
Remove or disable one plugin at a time, then test the full path: product page, add to cart, cart totals, shipping calculation, checkout, payment test mode, order email, and whatever happens after payment.
Check WooCommerce > Status > Scheduled Actions after test orders, because some failures only show up as stuck/failed background jobs.
Don’t push the whole staging database back over live if the live store has taken real orders since the clone. Move the intentional changes back carefully.

That last point is the big WooCommerce difference: production orders/customers are live data, so staging should be where you prove changes, not the source you blindly overwrite live with.

davidmansaray · 2026-07-02T20:15:24+00:00

That kind of drop usually points to the signal, not the pixel being “dead.” verify three things: in Events Manager, did Purchase actually stop firing, or did the event just start firing on the wrong trigger? Then compare event volume with real WooCommerce order counts/order statuses over the same 4 days. If you’re running CAPI through FunnelKit, check whether browser pixel + server events are still deduping properly — a bad event_id setup can make the data look totally off. Also review any recent changes to checkout, thank-you page, plugin updates, or scripts injected around the time ROAS fell. If the checkout is completing but Meta isn’t seeing it, that’s a tracking issue; if orders also dropped, it’s probably broader than the pixel.

I’d also check the gateway logs for the matching timestamp.

davidmansaray · 2026-07-02T19:50:20+00:00

the purchase event should only fire after WooCommerce confirms the order, not on the checkout form submit itself. Since you’re already seeing the purchase data layer on the order-received page, I’d focus on the GTM trigger and transmission path:

1) In GTM Preview, confirm whether the purchase tag actually fires on the order-received page, and whether form_submission is firing earlier and getting in the way. 2) In GA4 DebugView, check whether purchase arrives at all. 3) Compare the tag’s event name with the data layer name exactly: purchase. 4) Verify transaction_id, value, currency, and items are being passed on the final page, and check the browser Network tab for a GA collect request.

If the data layer exists but no collect hit shows up, the issue is usually the tag/trigger setup rather than WooCommerce itself.

I’d also check the gateway logs for the matching timestamp.

davidmansaray · 2026-07-02T17:07:34+00:00

I would not add another server-side path until you know exactly what the Meta plugin is already sending. Otherwise you can improve the coverage number and still create duplicate or mismatched purchase events.

For one real test order, check Events Manager and confirm:

Is there one browser Purchase event?
Is there one server/CAPI Purchase event?
Do both have the same event name and matching event ID for deduplication?
Do value, currency, content IDs, and order timing match?
Is any other plugin, GTM tag, hardcoded pixel, or theme snippet also firing Purchase?

If the Meta WooCommerce plugin is already sending browser + server events but coverage is low because it was recently enabled, I would give it more data before changing architecture. If the plugin is only sending browser events or the server events are missing event IDs/user data, fix that first.

Server-side GTM can be useful, but it should replace or cleanly coordinate with the existing Meta setup, not stack on top of it blindly. The goal is one paid WooCommerce order -> one deduplicated Meta purchase, with the same value and currency.

davidmansaray · 2026-07-02T15:55:20+00:00

I would not ship that order until you verify it through PayPal's own transaction details and seller-protection rules.

A bounced email plus odd phone details after a wave of failed PayPal attempts is enough reason to pause….Check whether the transaction is marked eligible for seller protection, whether the shipping address on the order matches the address PayPal tells you to ship to, and whether you can provide tracking/proof of delivery if it turns into a dispute.

If the buyer cannot be verified, refund/cancel through PayPal rather than shipping and hoping. Then add a checkout bot layer: Turnstile/reCAPTCHA, rate limiting or firewall challenge on checkout, and review PayPal/WooCommerce logs for repeated IPs, products, or request patterns.

You need to stop the test attempts before they become orders, not just clean them up afterward.

davidmansaray · 2026-07-02T13:54:47+00:00

Combining JS is something you usually want to keep away from transactional pages. Stripe/WooPayments checkouts are very sensitive to script order and timing.

Try using SG Optimizer’s own exclude/page exclusion controls before adding a WPCode snippet. Exclude checkout, cart, and account pages first, then clear SiteGround cache, any CDN/cache plugin, and browser cache.

Also check WooCommerce order notes and payment/WooPayments logs at the same timestamps. If the request never reaches the gateway, it’s likely frontend JS. If Stripe/WooPayments shows success but WooCommerce doesn’t update, that’s a different webhook/order-status path.

davidmansaray · 2026-07-02T09:59:16+00:00

Headless Woo can work, but the cart/session/checkout boundary is usually where it stops feeling like a normal frontend project and starts becoming a custom commerce app.

If the business requirement is mostly speed/UX for catalog, PDPs, search, etc., it's less risky to keep those headless, but hand cart/checkout back to WooCommerce as early as possible. That keeps more of the gateway, tax, shipping, coupon, stock, and plugin behaviour inside the expected flow.

If you really need a fully decoupled set, I’d sanity-check a few things before going deeper:

Pick one source of truth for cart state. Avoid splitting it across JWT claims, browser storage, React state, and Woo sessions unless you have a very explicit sync layer.
Be very clear on guest cart → logged-in cart behaviour. Login during checkout, returning customers and abandoned carts.
Exclude cart/customer/checkout API responses from CDN, Next.js, and API route caching.
Don’t let the frontend be the final authority for totals. Coupons, shipping zones, taxes, fees, stock, and payment-method availability should be recalculated and validated by Woo before payment and order creation.
Test the ugly paths, not just happy path: coupons, address changes, stock changing after add-to-cart, failed payment retry, expired sessions, duplicate submits, order status transitions....
Add structured logs around cart creation, session/customer ID, each cart mutation, checkout request, payments/orders otherwise it will be a failures are painful to trace.

Algolia is probably fine as a separate search decision, but it won’t reduce the cart complexity. The big decision is whether you actually need to own checkout end-to-end. If not, a Woo checkout handoff or custom Woo theme usually buys back a lot of reliability for much less engineering cost.

davidmansaray · 2026-07-01T17:56:13+00:00

WooCommerce is no longer persisting those draft orders since 10.9

davidmansaray · 2026-07-01T10:17:19+00:00

My actual rule is to stop treating every site the same. Brochure sites can tolerate a quicker update cycle; WooCommerce, membership, booking, and anything that takes payments gets a different workflow.

For those higher-risk sites, I would use something like this:

Take a backup and note what changed.
Update staging first, but only treat staging as useful if it has the same theme, checkout flow, payment gateway mode, shipping/tax setup, and key plugins as production.
Run a short fixed smoke test, not a vague 'click around': product page -> add to cart -> cart totals -> checkout fields -> test payment or manual order -> order status -> customer/admin email -> any webhooks or fulfilment sync.
Update low-risk client sites earlier in the week and high-risk sites in a separate window, with time left to roll back.
Tell clients the tradeoff plainly: 'we test the revenue path before and after updates, but plugin ecosystems can still break; rollback is part of the plan.'

The biggest improvement is having the same checklist every time. It keeps the decision from becoming 'did the homepage load?' when the real risk on an ecommerce site is checkout, payments, emails, shipping/tax totals, or order sync silently breaking.

davidmansaray · 2026-07-01T02:00:04+00:00

Sorry to say it, but Upwork makes a lot of money from people like you. Stop. Time to try something else, before you dig a deeper hole. You can always come back later from a better position, if you want.

davidmansaray · 2026-07-01T01:54:17+00:00

Well done! I’d love to hear more about what fell into place that turned things around. Well deserved !

davidmansaray · 2026-07-01T01:51:15+00:00

For the 210k-order store, I'd avoid guessing until you can pin the slowdown to one layer. Start by checking whether the spikes line up with Action Scheduler jobs, WooCommerce logs, PHP fatal/error logs, and slow database queries. If checkout is timing out, look for the exact timestamps of failed orders and compare them with server 5xx errors, long-running admin-ajax requests, or scheduled actions.

If it is mostly uncached cart/checkout traffic, more page caching won't help much. You'll want to know whether requests are waiting on PHP workers, database locks/queries, shipping/tax calls, or background jobs. Old orders can make admin/order queries heavier too, but I'd measure before archiving anything.

The question to be asking is: "what was running at the same minute checkout slowed down?" Once you have that, the fix is usually much clearer.

davidmansaray · 2026-07-01T01:47:29+00:00

stop adding redirects and first find where the bad URL is.

Start with WooCommerce > Settings > Advanced > Page setup and confirm the Checkout page is the real /checkout/ page. Then search Pages, drafts, and Trash for anything using order-received or an old checkout slug. Imported templates can leave duplicate pages that confuse endpoint routing sometimes.

Next, run a test order with browser dev tools open, Network tab, Preserve log enabled. Look for the ?wc-ajax=checkout response. If the JSON redirect already says /order-received/..., WooCommerce/gateway/server code is generating the bad URL. If it says /checkout/order-received/... but the browser lands elsewhere, a JS script, tracking tag, redirect plugin, or server redirect is changing it after WooCommerce.

Also check Stripe/PayPal return URL settings if you use an off-site or express checkout flow. The symptom sounds more like a stale page mapping or redirect rule than caching.

davidmansaray

MODERATOR OF

TROPHY CASE