Your uptime dashboard is lying to you. It says your site is online. The homepage loads. The SSL certificate is valid. Every pixel renders exactly where it should. Meanwhile, your store has not processed a real order in six hours, and the first person to tell you is your client wondering why the daily sales report flatlined.

This is the fundamental flaw in treating an e-commerce platform like a brochure site. Standard uptime monitoring asks exactly one question: did the server return a 200 OK status? For a WooCommerce store, that question misses the point entirely. The server can be humming, the checkout page can look pristine, and the money can still stop moving. That is a silent failure, and it is far more expensive than a noisy server crash.

When "Online" Means Nothing

A 200 response only proves that PHP finished executing and sent HTML back to the browser. It does not prove that Stripe's JavaScript loaded. It does not prove that the place-order button submits to a working endpoint. It does not prove that the webhook fired, the stock adjusted, or the confirmation email triggered. A visitor sees a fully loaded checkout, enters a card number, clicks buy, and nothing happens. Or worse, the order records as failed while the payment actually clears.

If your monitoring strategy begins and ends with pinging the homepage, you are watching the wrong stage. You will notice a theme crash that brings down the header. You will not notice a payment gateway stuck in test mode. You will only find out when someone checks the revenue graph or answers an angry phone call.

Five Ways a Store Dies Without Going Down

Here are the specific failures that keep a WooCommerce store at 100% uptime while conversion drops to zero:

  • Payment gateways get stuck in test mode. A developer switches Stripe or PayPal to sandbox to reproduce a bug, solves the problem, and forgets to flip the switch back. Real customers enter real card numbers and hit a test-mode wall. Sometimes the error is obvious; sometimes it is not, and the transaction simply hangs.
  • A plugin update breaks the checkout template. WooCommerce releases an update, or a page builder pushes a change, and the checkout form no longer renders correctly. The page loads, but the billing fields vanish, or the place-order button throws a JavaScript error on click. The server is fine. The user experience is broken.
  • Failed orders spike due to gateway errors. API keys expire. Currency mismatches appear. 3D Secure requirements change. These errors show up as failed orders in the WooCommerce admin, not as server errors in your uptime logs. Watch the wrong screen, and you will miss a slow-motion revenue leak.
  • The server-side order pipeline hangs. A third-party ERP integration, a custom stock-sync function, or a shipping-rate calculator times out after the customer clicks buy. The order stays in pending status indefinitely. The customer refreshes, gets confused, and leaves. Your hosting metrics still look green.
  • The order flow simply stops for no obvious reason. There is no fatal error. No plugin conflict. The cache simply starts serving stale checkout JavaScript. A consent-management banner blocks the payment iframe. A CDN edge node delivers an old version of a script. The site is online. The checkout is not.

Monitoring What Actually Matters

To catch these failures, you have to stop watching the infrastructure and start watching the business logic. Here is how to build a monitoring strategy that respects the complexity of a real transaction flow.

Monitor the order flow, not just uptime. Track whether a product can be added to the cart, whether the checkout endpoint responds with valid JSON, and whether the thank-you page resolves after a successful payment. If you rely on external ping tools, configure them to hit the critical path, not just the domain root.

Compare failed orders against a seven-day baseline. Do not use absolute numbers. Five failed orders in an hour might be normal for a Monday morning after a promotion. Five failed orders in an hour on a quiet Wednesday afternoon is a red flag. Look at deviation from your own rolling baseline, not arbitrary thresholds.

بررسی کنید که آیا درگاه‌های زنده در حالت sandbox هستند یا خیر. این مورد را به چک‌لیست استقرار (deployment) و تست‌های خودکار خود اضافه کنید. تنظیمات درگاه فعال را بازبینی کنید یا کلیدهای API عمومی را تجزیه کنید تا مطمئن شوید که این‌ها اعتبارنامه‌های محیط عملیاتی (production) هستند. یک فروشگاه هرگز نباید در حالی که به یک محیط تست متصل است، آنلاین شود.

یک تست دود (smoke test) روزانه در سمت سرور اجرا کنید. این مؤثرترین شبکه ایمنی برای شناسایی خرابی فرآیند پرداخت (checkout) پیش از آن است که چشم انسان متوجه آن شود.

ساخت تست دود روزانه

یک تست دود مناسب، یک سفارش واقعی ایجاد می‌کند بدون اینکه باعث ایجاد آشفتگی در پایگاه داده شما شود. فرآیند به این صورت است: یک محصول مجازی مخفی ایجاد کنید، یک سفارش تست را از طریق WooCommerce API اجرا کنید، صحت محاسبه مجموع مبالغ را تأیید کنید، مراحل وضعیت سفارش را طی کنید و سپس تمام آثار باقی‌مانده را حذف کنید.

جزئیات پیاده‌سازی اهمیت دارند. اگر فرآیند پاک‌سازی را با دقت انجام ندهید، گزارش‌های شما با سفارش‌های جعلی و محصولات خیالی پر خواهد شد.

ایمیل‌های WooCommerce را در طول تست متوقف کنید. آخرین چیزی که می‌خواهید این است که صاحب فروشگاه یا یک مدیر واقعی، ساعت ۳ صبح به دلیل اجرای چک‌لیست روزانه توسط یک cron job، ایمیل «سفارش جدید» دریافت کند. اعلان‌های خروجی را برای مدت اجرای اسکریپت غیرفعال کنید، یا از یک فیلتر برای مسدود کردن هر ایمیلی که به شناسه‌های (ID) سفارش‌های تست مربوط است، استفاده کنید.

در صورت کرش کردن اسکریپت، از یک تابع shutdown برای پاک‌سازی داده‌ها استفاده کنید. PHP به شما اجازه می‌دهد یک تابع shutdown ثبت کنید که حتی در صورت بروز یک خطای مهلک (fatal error) و متوقف شدن فرآیند، اجرا شود. اگر تست دود شما در حین محاسبه مالیات یا تغییر وضعیت سفارش از کار بیفتد، آن روتین پاک‌سازی همچنان باید اجرا شود؛ در غیر این صورت، سفارش‌ها و محصولات یتیم (بدون صاحب) باقی می‌مانند.

شناسه‌ها (IDs) را بلافاصله پس از ایجاد ثبت کنید تا از باقی ماندن داده‌های یتیم جلوگیری شود. به محض ایجاد محصول مجازی، ID آن را ذخیره کنید. به محض ایجاد سفارش تست، ID آن را ذخیره کنید. این‌ها را بلافاصله در متغیرها ذخیره کنید. تا پایان اسکریپت منتظر نمانید تا از پایگاه داده بپرسید چه چیزی ساخته‌اید. اگر اسکریپت در میانه راه با شکست مواجه شد، باید آن IDها را از قبل در اختیار داشته باشید تا مدیریت shutdown دقیقاً بداند چه چیزی را باید حذف کند.

این تست رابط کاربری (UI) را دور می‌زند و مستقیماً با لایه اپلیکیشن صحبت می‌کند. این موضوع مهم است. فرانت‌اند (front end) ممکن است کش شده باشد، فشرده (minified) شده باشد یا توسط ده‌ها افزونه مرورگر دستکاری شده باشد. API نشان‌دهنده حقیقت اصلی است: آیا WooCommerce هنوز می‌تواند یک سفارش را ایجاد، محاسبه و تغییر وضعیت دهد؟

دو لایه حفاظتی

شما به هر دو نوع نظارت خارجی و داخلی نیاز دارید و باید درک کنید که هر لایه واقعاً چه چیزی را به شما می‌گوید.

نظارت خارجی به این سوال پاسخ می‌دهد: «آیا مردم می‌توانند به سایت دسترسی پیدا کنند؟» از آن برای شناسایی مشکلات DNS، انقضای SSL، از کار افتادن سرورها و قطعی شبکه استفاده کنید. این اولین خط دفاعی شما در برابر خرابی‌های زیرساختی است.

نظارت داخلی به این سوال پاسخ می‌دهد: «آیا مردم می‌توانند چیزی بخرند؟» این نظارت درون اپلیکیشن شما قرار دارد. نرخ شکست سفارش‌ها، حالت‌های درگاه، عملکرد پایگاه داده در حین پرداخت و نتایج تست دود روزانه شما را بررسی می‌کند. این لایه، شکست‌های منطق تجاری (business-logic) را شناسایی می‌کند که هیچ سرویس ping خارجی هرگز قادر به دیدن آن‌ها نخواهد بود.

یک قطعی (outage) پر سر و صداست. سایت از دسترس خارج می‌شود، هشدار فعال می‌شود و شما آن را رفع می‌کنید. مشتریان ممکن است غر بزنند، اما اغلب بازمی‌گردند. اما یک فرآیند پرداخت خراب، بی‌صدا است. تبلیغات شما همچنان اجرا می‌شوند، بودجه جذب مشتری شما همچنان در حال سوختن است و مشتریان بدون گفتن کلمه‌ای سایت را ترک می‌کنند. در تمام این مدت، داشبورد زمان بالا بودن سایت (uptime) شما با رنگ سبز اطمینان‌بخش باقی می‌ماند.

دیگر به صفحه اصلی نگاه نکنید. به پول نگاه کنید.