لوحة بيانات وقت التشغيل (uptime dashboard) تخدعك. تقول إن موقعك متصل بالإنترنت. الصفحة الرئيسية تعمل. شهادة SSL صالحة. كل بكسل يظهر في مكانه تماماً. وفي هذه الأثناء، لم يقم متجرك بمعالجة أي طلب حقيقي منذ ست ساعات، وأول شخص يخبرك بذلك هو عميلك الذي يتساءل عن سبب توقف تقرير المبيعات اليومي.

هذا هو الخلل الجوهري في التعامل مع منصة التجارة الإلكترونية كموقع تعريفي (brochure site). تطلب مراقبة وقت التشغيل القياسية سؤالاً واحداً فقط: هل أعاد الخادم حالة 200 OK؟ بالنسبة لمتجر WooCommerce، فإن هذا السؤال يخطئ الهدف تماماً. يمكن للخادم أن يعمل بسلاسة، وصفحة الدفع أن تبدو مثالية، ومع ذلك قد تتوقف الأموال عن التدفق. هذا فشل صامت، وهو أكثر تكلفة بكثير من تعطل الخادم الصاخب.

عندما لا يعني مصطلح "متصل" شيئاً

استجابة 200 تثبت فقط أن PHP انتهى من التنفيذ وأرسل HTML إلى المتصفح. هي لا تثبت أن JavaScript الخاص بـ Stripe قد تم تحميله. ولا تثبت أن زر "إتمام الطلب" (place-order button) يرسل البيانات إلى نقطة نهاية (endpoint) تعمل. ولا تثبت أن الـ webhook قد تم تفعيله، أو أن المخزون قد تم تعديله، أو أن رسالة التأكيد قد أُرسلت. يرى الزائر صفحة دفع محملة بالكامل، ويدخل رقم البطاقة، وينقر على "شراء"، ولا يحدث شيء. أو والأسوأ من ذلك، يتم تسجيل الطلب كفاشل بينما تتم عملية الدفع بالفعل.

إذا كانت استراتيجية المراقبة الخاصة بك تبدأ وتنتهي بمجرد فحص الصفحة الرئيسية (pinging the homepage)، فأنت تراقب المسرح الخطأ. ستلاحظ تعطل القالب (theme crash) الذي يؤدي إلى اختفاء الترويسة (header). لكنك لن تلاحظ بوابة دفع عالقة في وضع الاختبار (test mode). لن تكتشف الأمر إلا عندما يتحقق شخص ما من رسم المبيعات البياني أو يرد على مكالمة هاتفية غاضبة.

خمس طرق يموت بها المتجر دون أن يتوقف عن العمل

إليك الإخفاقات المحددة التي تبقي متجر WooCommerce عند نسبة تشغيل 100% بينما تنخفض نسبة التحويل إلى الصفر:

  • بوابات الدفع تعلق في وضع الاختبار (test mode). يقوم المطور بتحويل Stripe أو PayPal إلى وضع sandbox لإعادة إنتاج خطأ ما، ثم يحل المشكلة وينسى إعادة المفتاح إلى وضعه الطبيعي. يدخل العملاء الحقيقيون أرقام بطاقات حقيقية ويصطدمون بجدار وضع الاختبار. أحياناً يكون الخطأ واضحاً، وأحياناً لا يكون كذلك، وتتعلق المعاملة ببساطة.
  • تحديث أحد الإضافات (plugin) يكسر قالب الدفع. يصدر WooCommerce تحديثاً، أو يقوم أداة بناء الصفحات (page builder) بإجراء تغيير، فيتوقف نموذج الدفع عن الظهور بشكل صحيح. يتم تحميل الصفحة، لكن حقول الفواتير تختفي، أو يظهر خطأ JavaScript عند النقر على زر إتمام الطلب. الخادم يعمل بشكل جيد، لكن تجربة المستخدم معطلة.
  • ارتفاع الطلبات الفاشلة بسبب أخطاء البوابة. تنتهي صلاحية مفاتيح API. تظهر عدم تطابقات في العملات. تتغير متطلبات 3D Secure. تظهر هذه الأخطاء كطلبات فاشلة في لوحة تحكم WooCommerce، وليس كأخطاء خادم في سجلات وقت التشغيل الخاصة بك. إذا كنت تراقب الشاشة الخطأ، فستفوتك عملية تسرب الإيرادات البطيئة.
  • تعطل مسار الطلبات من جانب الخادم (server-side order pipeline). قد يتوقف تكامل ERP من طرف ثالث، أو وظيفة مزامنة مخزون مخصصة، أو حاسبة أسعار الشحن عن الاستجابة بعد أن ينقر العميل على شراء. يظل الطلب في حالة "قيد الانتظار" (pending) إلى أجل غير مسمى. يقوم العميل بتحديث الصفحة، ويشعر بالارتباك، ثم يغادر. بينما لا تزال مقاييس الاستضافة الخاصة بك تظهر باللون الأخضر.
  • يتوقف تدفق الطلبات ببساطة دون سبب واضح. لا يوجد خطأ فادح. لا يوجد تعارض في الإضافات. ببساطة، يبدأ التخزين المؤقت (cache) في تقديم نسخة قديمة من JavaScript الخاص بالدفع. أو قد يحجب بنر إدارة الموافقة (consent-management banner) إطار الدفع (iframe). أو تقوم عقدة حافة (edge node) في CDN بتقديم نسخة قديمة من نص برمجي (script). الموقع متصل، لكن عملية الدفع لا تعمل.

مراقبة ما يهم حقاً

لاكتشاف هذه الإخفاقات، عليك التوقف عن مراقبة البنية التحتية والبدء في مراقبة منطق العمل (business logic). إليك كيفية بناء استراتيجية مراقبة تحترم تعقيد تدفق المعاملات الحقيقية.

راقب تدفق الطلبات، وليس فقط وقت التشغيل. تتبع ما إذا كان يمكن إضافة منتج إلى السلة، وما إذا كانت نقطة نهاية الدفع (checkout endpoint) تستجيب بـ JSON صالح، وما إذا كانت صفحة "شكراً لك" تظهر بعد عملية دفع ناجحة. إذا كنت تعتمد على أدوات ping خارجية، فقم بتكوينها لتستهدف المسار الحرج (critical path)، وليس فقط جذر النطاق (domain root).

قارن الطلبات الفاشلة بخط أساس (baseline) لمدة سبعة أيام. لا تستخدم الأرقام المطلقة. قد يكون وجود خمسة طلبات فاشلة في ساعة واحدة أمراً طبيعياً في صباح يوم اثنين بعد حملة ترويجية. لكن خمسة طلبات فاشلة في ساعة واحدة في بعد ظهر يوم أربعاء هادئ يعد علامة خطر. انظر إلى الانحراف عن خط الأساس المتغير الخاص بك، وليس إلى عتبات عشوائية.

Check if live gateways are in sandbox mode. Make this part of your deployment checklist and your automated tests. Inspect the active gateway settings, or parse the public API keys to ensure they are production credentials. A store should never go live while pointing to a test environment.

Run a daily server-side smoke test. This is the single most effective safety net for catching a dead checkout before human eyes do.

Building the Daily Smoke Test

A proper smoke test creates a realistic order without leaving chaos in your database. The process looks like this: generate a hidden virtual product, run a test order through the WooCommerce API, verify that totals calculate correctly, step the order through its statuses, and then delete every artifact.

The implementation details matter. If you do not handle cleanup carefully, your reports fill with fake orders and phantom products.

Suppress WooCommerce emails during the test. The absolute last thing you want is the store owner or a real admin receiving a "New Order" email at 3:00 AM because a cron job ran its daily check. Disable outgoing notifications for the duration of the script, or use a filter to block any email tied to test order IDs.

Use a shutdown function to clean up data if the script crashes. PHP lets you register a shutdown function that fires even when a fatal error kills the process. If your smoke test dies while calculating tax or transitioning order statuses, that cleanup routine must still run. Otherwise you leave orphaned orders and products behind.

Record IDs immediately after creation to avoid orphan data. The moment the virtual product is created, capture its ID. The moment the test order is created, capture its ID. Store these in variables right away. Do not wait until the end of the script to ask the database what you just made. If the script fails mid-flight, you need those IDs already in hand so your shutdown handler knows exactly what to delete.

This test bypasses the user interface and talks directly to the application layer. That is important. The front end might be cached, minified, or manipulated by a dozen browser extensions. The API represents the core truth: can WooCommerce still create, calculate, and transition an order?

Two Layers of Protection

You need both external and internal monitoring, and you need to understand what each layer actually tells you.

External monitoring answers the question, "Can people reach the site?" Use it to catch DNS issues, SSL expiration, downed servers, and network partitioning. It is your first line of defense against infrastructure failures.

Internal monitoring answers the question, "Can people buy something?" It lives inside your application. It looks at order failure rates, gateway modes, database performance during checkout, and the results of your daily smoke test. It catches business-logic failures that no external ping service will ever see.

An outage is loud. The site goes down, the alert fires, and you fix it. Customers might grumble, but they often return. A broken checkout is quiet. Your ads keep running, your acquisition budget keeps burning, and customers leave without saying a word. Your uptime dashboard stays a reassuring shade of green the entire time.

Stop watching the homepage. Start watching the money.