كيف تراقب تطبيقك وتصلح أخطاءه تلقائيًا باستخدام Replit؟

Monitoring Agent وكيل داخل Replit يتعامل مع التطبيق بعد نشره، لا مع شاشة البناء وحدها. يقرأ إشارات التشغيل المتاحة مثل سجلات الأخطاء وأخطاء HTTP وبطء الطلبات، ويستعين بالشيفرة ومؤشرات الإنتاج للتحقيق. عندما تسمح له بإصلاح تلقائي، يمكنه محاولة تعديل السبب القابل للمعالجة والتحقق من التغيير. نشر هذا التغيير يحتاج قرارًا مستقلًا في الإعدادات.

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

الميزة مفيدة لصاحب منتج لا يقرأ السجلات عادة، لأنها تتيح أسئلة مباشرة مثل: لماذا ظهرت أخطاء 500 خلال الساعة الماضية؟ يمكنك سؤال Agent عن الإنتاج دون تشغيل Auto-fix ودون انتظار تنبيه. يظل نجاح الإصلاح غير مضمون؛ بعض الأعطال سببها خدمة خارجية أو معلومة ناقصة أو قرار يحتاج صاحب التطبيق.

المصدر: إعلان Monitoring Agent — 22 أكتوبر 2026المصدر: وثائق Monitoring Agent والإعدادات والتنبيهات

تبدأ الدورة من تطبيق منشور ومراقبة مفعلة. تراقب الفحوص التلقائية سجلات أخطاء التطبيق وأخطاء HTTP وزمن الاستجابة. فحوص التوافر Uptime منفصلة: تجري وفق جدول دوري، ولا تحدد المصادر المراجعة الفاصل الزمني الدقيق. لا نفترض رصدًا لحظيًا أو مدة ثابتة لإصلاح المشكلة.

عند ظهور تنبيه، يستطيع الوكيل التحقيق باستخدام مؤشرات الإنتاج وسجلات التشغيل والشيفرة. إذا كان Auto-fix مفعّلًا وحدد سببًا يمكن العمل عليه، يحاول الإصلاح ويتحقق من التعديل. هذا لا يعني أنه شغّل كل الاختبارات التي يحتاجها منتجك؛ راجع ما اختبره بالفعل وما لم يختبره، خصوصًا الوظائف التي تمس البيانات والمال.

إذا فعلت Auto-republish يستطيع نشر الإصلاح الذي تحقق منه. بدونه تراجع النتيجة في محادثة Agent وتنشر يدويًا. يصف الإعلان إرسال ملخص بالبريد لما حدث، ويمكن متابعة نتائج الوكيل والتنبيهات. المخطط أدناه يوضح المسار الممكن، لا ضمانًا بأن كل تنبيه سيصل إلى إصلاح أو نشر ناجح.

1. 1متابعة التطبيق
2. 2رصد إشارات العطل
3. 3قراءة السجلات
4. 4تحديد سبب محتمل
5. 5إصلاح إن سمحت
6. 6اختبار التعديل
7. 7نشر إن سمحت
8. 8مراجعة التقرير

المصدر: إعلان Monitoring Agent — 22 أكتوبر 2026المصدر: وثائق Monitoring Agent والإعدادات والتنبيهاتالمصدر: مراقبة التطبيق المنشور والسجلات

أعلنت Replit عن App Monitoring في 29 أبريل 2026، ثم عن Monitoring Agent في 22 أكتوبر 2026. الإصدار الأول لم يكن مجرد إشعار: أتاح التحقيق مع Agent وقراءة سجلات الإنتاج ووصولًا للقراءة فقط إلى قاعدة بيانات الإنتاج. الإضافة الجديدة توصل التحقيق بمحاولة الإصلاح والتحقق وخيار النشر التلقائي.

قد تختلف أسماء الشاشات بين إعلان أبريل والوثائق الحالية. الإعلان القديم يذكر Analytics وخيار Investigate downtime with Agent، بينما توجه الوثائق الحالية إلى Monitoring. استخدم التوجيه الحالي بدل الجمع بين صور وعبارات من واجهات زمنية مختلفة.

المصدر: إعلان Monitoring Agent — 22 أكتوبر 2026المصدر: وثائق Monitoring Agent والإعدادات والتنبيهاتالمصدر: إعلان App Monitoring — 29 أبريل 2026

Monitoring alerts يشغّل تنبيهات المراقبة للتطبيق المنشور. تلقي التنبيه لا يمنح الوكيل إذن تغيير الشيفرة. استخدم هذه المرحلة أولًا لفهم الأخطاء المعتادة وتحديد من يستقبل الإشعارات، خاصة عندما لا تكون لديك اختبارات كافية أو عندما تعتمد وظائفك على بيانات حساسة.

Auto-fix يسمح بالتحقيق ومحاولة الإصلاح في الخلفية استجابة للتنبيهات. لكنه لا يجيز نشر التعديلات وحده. هذا الفصل مناسب عندما تريد مساعدة في التشخيص والتنفيذ مع إبقاء قرار إطلاق التغيير بيدك. لا تعتبر أمرًا نصيًا مثل «لا تنشر» بديلًا عن تعطيل صلاحية النشر التلقائي من الإعدادات.

Auto-republish يسمح بنشر الإصلاح المتحقق منه تلقائيًا، وهو موصوف رسميًا بأنه تجريبي ويتطلب Auto-fix. مثال الوثائق يعرض الإصلاح والنشر التلقائيين مغلقين، لكنه ليس دليلًا على الإعداد الافتراضي لجميع الحسابات. راجع الحالة الفعلية في مشروعك، ولا تفترض أن الميزة كلها تجريبية لأن هذا الخيار وحده تجريبي.

توصيتنا التحريرية: ابدأ بالتنبيهات فقط، ثم بالإصلاح مع مراجعة النشر يدويًا. فكر في النشر التلقائي لمشروع منخفض المخاطر بعد توفير اختبارات وخطة تراجع. أما المدفوعات والصلاحيات وترحيلات البيانات، فإصلاح صغير غير متوقع قد يضرها. قراءة قاعدة الإنتاج فقط أثناء التحقيق لا تعني أن التعديلات المنشورة لن تؤثر عليها.

المصدر: وثائق Monitoring Agent والإعدادات والتنبيهات

ادخل حساب Replit وافتح المشروع المقصود، وتأكد أن التطبيق منشور. قبل أول نشر لا توجد بيئة منشورة تراقبها الأداة. أثناء أول نشر يظهر Suggested add-ons ثم Enable Active monitoring؛ تفعيل ذلك يشغّل فحوص التوافر حيث تتاح، وتسري الإعدادات عند النشر. فحوص Uptime تحتاج خطة مدفوعة ولا تتاح لـScheduled Deployments؛ هذا قيد محدد لا جدول شامل لأهلية كل قدرات الوكيل.

لتطبيق منشور بالفعل، افتح أداة Publishing وإعدادات نشر التطبيق، ثم فعّل Monitoring alerts. قرر على نحو منفصل إن كنت تريد Auto-fix وAuto-republish. تحفظ تغييرات هذه الإعدادات فورًا؛ تفعيل التنبيهات لا يحتاج إعادة نشر. الإعدادات لكل تطبيق، فلا تفترض أن ضبط مشروع يضبط مشروعاتك الأخرى.

لمتابعة التشغيل افتح Tools ثم Replit Cloud ثم Monitoring وفق الوثائق الحالية. راجع Monitoring alerts وحالتي Active وResolved، وافتح التنبيه لرؤية سبب إطلاقه وعدد مرات رصده. تعني Cannot measure أن المراقبة لا تستطيع تقييمه حاليًا، لا أن التطبيق سليم. تعرض Resolved التنبيهات التي زال أثرها خلال آخر 30 يومًا.

للإشعارات الشخصية افتح Settings ثم Notifications ثم Active monitoring alerts. يمكنك اختيار Critical severity only أو High severity and above أو Medium severity and above أو All severity levels أو No emails. إذا تعذر اختيار الشدة فعّل رسائل تنبيهات الإنتاج. إعداد Monitoring alert recipients في Account advanced settings منفصل ويتيح للمسؤولين Off أو Admins أو Custom. إيقاف البريد لا يوقف المراقبة أو Auto-fix.

اختبر الإعداد على نسخة تجريبية بلا بيانات حقيقية، أو اطلب تحقيقًا للقراءة فقط في حادثة معروفة. لا تتعمد كسر الإنتاج لإنتاج تنبيه، ولا تنفذ اختبار ضغط على المستخدمين. تحقق من وصول الرسالة وظهور التقرير وقدرتك على مراجعة التغييرات، واضبط ميزانية الاستخدام قبل السماح بالعمل الخلفي. هذه خطوات أمان مقترحة؛ لم نشغّل Monitoring Agent على مشروع حقيقي لإعداد هذا الدليل.

المصدر: وثائق Monitoring Agent والإعدادات والتنبيهاتالمصدر: مراقبة التطبيق المنشور والسجلاتالمصدر: إدارة الاستهلاك وحدود الإنفاق

الفحوص التلقائية تركز على ثلاث إشارات: سجلات أخطاء التطبيق، وأخطاء HTTP، وبطء الطلبات. قائمة البيانات التي يستطيع Agent الاستعلام عنها أوسع، وقد تختلف حسب نوع النشر ومزود السحابة. وجود مؤشر للاستعلام لا يثبت وجود تنبيه تلقائي لكل تغير فيه.

Uptime يبين نسبة الوقت الذي كان التطبيق متاحًا وتاريخه الأخير، وليس صحة كل وظيفة داخله. الطلبات تبين حركة المرور، وحالات HTTP تساعد على رصد ارتفاع 4xx و5xx. لا تعتبر عناوين IP الفريدة عدد أشخاص فريدين. الرسوم تعرض كذلك مدة الطلبات واستهلاك المعالج والذاكرة؛ القفزة العابرة تختلف عن ارتفاع مستمر يصاحبه بطء.

تتيح الاستعلامات المتاحة عدّ الطلبات والأخطاء وقياس زمن الاستجابة لكل نقطة نهاية، وبيانات مثل عدد النسخ النشطة وزمن بدء التشغيل ووقت تشغيل النسخة واستهلاك القرص وخروج البيانات للشبكة. وقت تشغيل نسخة الخادم ليس بالضرورة نسبة توافر التطبيق من الخارج. اسأل عن المسار والفترة والمنطقة الزمنية، بدل سؤال عام لا يمكن مقارنته.

p50 يعني أن نحو نصف الطلبات المقاسة زمنها عند هذه القيمة أو أقل، وp95 أن نحو 95% كذلك، وp99 أن نحو 99% كذلك. قد يبدو المتوسط جيدًا بينما تواجه فئة صغيرة تأخرًا كبيرًا يكشفه p99. هذه قراءة إحصائية، لا حدود سرعة ثابتة لكل تطبيق. قارن الفترات المتشابهة وانتبه لقلة عدد الطلبات.

تحتفظ Replit بسجلات النشر 30 يومًا وفق وثائق المراقبة، مع مرشحات Errors only وSearch وDate. لا نعمم مدة السجلات على جميع المؤشرات. استخدم سجلات منقحة، ولا تطبع كلمات مرور أو بيانات جلسات لتسهيل التشخيص.

المصدر: وثائق Monitoring Agent والإعدادات والتنبيهاتالمصدر: مراقبة التطبيق المنشور والسجلات

الأمثلة الآتية توضيحية وليست حوادث شغّلناها أو نتائج مضمونة. في كل حالة اطلب الدليل أولًا، ثم اختبر السبب، وبعد ذلك اعتمد التعديل. التشابه الزمني بين مؤشر وعطل لا يكفي وحده لإثبات السبب.

المصدر: وثائق Monitoring Agent والإعدادات والتنبيهات

المراقبة وفحص الجودة يكمل أحدهما الآخر. افتح الرابط العام لتطبيقك المنشور وانسخه، ثم ألصقه في النموذج أدناه وحدد أداة البناء؛ إذا كان المشروع على Replit فاختر Replit بدل القيمة الافتراضية Lovable. يمكنك إضافة رابط مستودع GitHub عام إن رغبت في فحص أجزاء من الشيفرة المتاحة. لا ترفق مستودعًا خاصًا أو أسرارًا.

ابدأ الفحص وانتظر انتقالك إلى التقرير. اقرأ الدليل والموقع المتأثر وسبب المشكلة قبل تنفيذ التوصية. رتب العمل Critical ثم Important ثم Polish، وانسخ أوامر الإصلاح المناسبة إلى أداة التطوير. اطلب التحقق منها في الشيفرة الحالية، ثم اختبر التعديل وأعد الفحص عند الحاجة. لا يغيّر VibeQuality ملفات مشروعك ولا ينشرها تلقائيًا.

في الوصول وSEO يقرأ الفاحص استجابة الرابط ومعلومات HTML المتاحة: عنوان الصفحة والوصف وCanonical وبيانات المشاركة وviewport وبعض إعدادات الفهرسة مثل noindex وrobots.txt. وفي المحتوى وGEO يرصد مؤشرات من النص والبنية المتاحة وقد يستعين بتقييم ذكي؛ لا يحتفظ بالملاحظة الذكية إلا إذا طابق اقتباسها النص حرفيًا. المطابقة تمنع اقتباسًا مختلقًا، لكنها ليست ضمانًا لكل استنتاج أو للظهور في إجابات الذكاء الاصطناعي.

في الجوال والوصول يرصد مؤشرات مثل تهيئة العرض ونصوص الصور وتسميات الحقول مما يتاح قراءته. لا يشغّل تجربة جوال كاملة ولا يثبت أن كل نموذج يعمل. وفي الأمان الظاهر يفحص مؤشرات محددة مثل HTTPS وبعض الترويسات والمحتوى المختلط والأسرار المكشوفة والملفات الحساسة العامة. هذا ليس اختبار اختراق شاملًا ولا دليلًا على سلامة الصلاحيات الداخلية.

فحص GitHub اختياري ومحدود بملفات مختارة وأنماط معروفة، ومنها أسرار مكشوفة ومفاتيح حساسة في الواجهة وأنماط حماية الجداول في ملفات الترحيل. لا يقرأ كل المستودع ولا يثبت أن سياسات قاعدة الإنتاج تطابق ملفاتك. الصفحات الديناميكية والحماية من الزواحف قد تحدان من الأدلة. الدرجة مؤشر لما رُصد، لا شهادة أمان أو نسبة مؤكدة لجاهزية المنتج.

انسخ الأمر الأقرب لحالتك، ثم أضف المسار والفترة الزمنية ووصف العطل دون بيانات حساسة. الأوامر طلبات عمل وليست وظائف جديدة أو تجاوزًا لحدود الحساب. إذا لم تتوفر بيانات، اطلب من الوكيل التصريح بذلك. تفعيل صلاحيات الإصلاح أو النشر يتم من الإعدادات، لا من نسخ الأمر وحده.

لا يوجد تكامل آلي مباشر هنا بين تقرير VibeQuality وReplit. بعد الفحص تنقل النتائج أو الأوامر يدويًا إلى محادثة التطوير؛ راجع محتواها واحذف أي بيانات خاصة قبل الإرسال. كل زر أدناه ينسخ أمرًا مستقلًا.

قد يكتشف التنبيه أثر المشكلة دون أن يعرف سببها أو يستطيع إصلاحها. انقطاع مزود خارجي أو استنفاد حصة خدمة يحتاج إجراء لدى المزود؛ إعادة المحاولة العشوائية قد تزيد الحمل أو تكرر معاملة مالية. لا تعد ارتفاع الموارد سببًا نهائيًا قبل مراجعة الطلبات والشيفرة.

قد يحمل الإصلاح تغييرًا غير مرغوب، خاصة في ترحيلات البيانات أو الفهارس أو الصلاحيات. احتفظ بنسخة احتياطية وخطة تراجع مختبرة، ولا تفترض أن التراجع عن الشيفرة يعيد بيانات حُذفت أو عُدلت. اطلب مراجعة بشرية للتعديلات الحساسة، واختبر النجاح والفشل وحسابين مختلفين عندما تمس المشكلة عزل بيانات المستخدمين.

لا تشارك مفاتيح سرية أو رموز جلسات أو سجلات تكشف بيانات شخصية في الأوامر وتقارير الفحص. إذا ظهر سر في ملف عام، احذفه وبدله لدى الخدمة؛ حذف النص وحده لا يلغي صلاحية المفتاح. مبدأ العمل في VibeQuality هو نتيجة بدليل قابل للتحقق، مع فصل ما لم يمكن إثباته عن الحكم النهائي.

المصدر: وثائق Monitoring Agent والإعدادات والتنبيهاتالمصدر: إعلان App Monitoring — 29 أبريل 2026

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

الرحلة العملية: مراقبة التطبيق عبر Replit ← اكتشاف المشكلة ← إصلاحها واختبارها ← فحص الجوانب المدعومة عبر VibeQuality ← مراجعة النتائج ← إعادة التحقق بعد التعديل. يفحص كل طرف أدلة مختلفة؛ لا يستبدل فحص صفحة عامة سجلات الخادم ولا تستبدل سلامة التشغيل جودة بيانات الصفحات أو قابلية فهرستها.

إذا مس الإصلاح قاعدة البيانات أو الهوية أو المدفوعات، ارجع إلى منهج البناء الآمن وراجع الصلاحيات والاختبارات والنسخ الاحتياطية. أنهيت بناء تطبيقك أو إصلاح أخطائه؟ افحص جاهزيته باستخدام VibeQuality، مع إبقاء المراجعة الداخلية للوظائف الحساسة جزءًا مستقلًا من قرار الإطلاق.

راجع منهج البناء الآمن قبل تغييرات الصلاحيات والبيانات.

لا تعرض الوثائق المراجعة سعرًا ثابتًا لكل تنبيه أو إصلاح. تنص على أن تشغيل Monitoring Agent قد يسبب رسوم استخدام Agent. لذلك لا نصفه بأنه مجاني أو غير محدود. فحوص التوافر تحتاج خطة مدفوعة، لكن لم نعثر على جدول شامل يحدد أهلية جميع قدرات Monitoring Agent لكل خطة ونوع نشر.

وقت مراجعة صفحة التسعير في 22 أكتوبر 2026، عرضت Core بسعر 20 دولارًا شهريًا أو ما يعادل 18 دولارًا شهريًا عند الفوترة السنوية، وPro بسعر 100 دولار شهريًا أو ما يعادل 90 دولارًا عند الفوترة السنوية، وEnterprise بتسعير مخصص. هذه أسعار اشتراكات عامة وليست سعر إضافة المراقبة، وقد تطبق ضرائب وتتغير العروض؛ راجع السعر وشروط حسابك قبل الشراء.

فوترة أعمال Agent المدفوعة تعتمد على الجهد وتعقيد الطلب. تستخدم الأرصدة الشهرية لخدمات Agent وخدمات Replit السحابية وفق الخطة، فلا تحسب كل الرصيد ميزانية مراقبة فقط. الاستضافة والبيانات والتخزين لها تكاليفها أيضًا؛ إعادة النشر لا تعني إعفاء التشغيل من رسومه.

تابع صفحة Usage وصفِّ البيانات حسب المشروع والفترة والمورد، واضبط تنبيهات الإنفاق وحدود الميزانية المتاحة. قد تتأخر بيانات استخدام Agent حتى 30 دقيقة، فلا تفترض أنها لحظية. للحد من العمل المكلف، حدد نافذة التحقيق والمسار المتعطل، واطلب خطة قبل تعديلات كبيرة، ولا تشغّل إصلاحات متكررة لخطأ سببه مزود خارجي.

المصدر: وثائق Monitoring Agent والإعدادات والتنبيهاتالمصدر: مراقبة التطبيق المنشور والسجلاتالمصدر: تسعير Replit الحاليالمصدر: فوترة استخدام Agentالمصدر: إدارة الاستهلاك وحدود الإنفاق

الوثائق تصف الميزة للتطبيقات المنشورة داخل Replit. وجود مشروع بُني باستخدام Lovable أو أداة أخرى لا يمنحه مراقبة Replit تلقائيًا، ولا تدعم المصادر المراجعة تعميم تشغيلها مباشرة على كل استضافة خارجية. نقل مشروع ونشره على Replit خطوة منفصلة تحتاج التحقق من توافقه واستضافته وبياناته.

أما VibeQuality فيفحص الأدلة المتاحة من الرابط العام ضمن نطاقه الحالي بغض النظر عن اسم أداة البناء؛ اختيار الأداة لا يمنحه وصولًا إلى بيئتها الخاصة. يمكن فحص مشروع Lovable أو Bolt أو غيرهما، لكن لا توجد من ذلك صلاحية قراءة سجلات التشغيل الداخلية أو إصلاح المشروع ونشره ذاتيًا.

المصدر: وثائق Monitoring Agent والإعدادات والتنبيهاتالمصدر: مراقبة التطبيق المنشور والسجلات

الجدول يوضح اختلاف الوظيفة لا منافسة بين منتجين. كلمة «متاح» لا تعني تغطية شاملة، وقد تتوقف النتيجة على الإعدادات ونوع النشر والأدلة التي أمكن الوصول إليها.

انتقل إلى فحص الجوانب العامة لمشروعك عندما تحتاج أدلة مكملة لمراقبة التشغيل.

المصدر: وثائق Monitoring Agent والإعدادات والتنبيهاتالمصدر: مراقبة التطبيق المنشور والسجلات

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

أعد الفحص بعد التعديلات المهمة، واحتفظ بقائمة لما أثبته اختبار فعلي وما يحتاج مراجعة. تعلم قواعد SEO وGEO يساعد على وضوح الصفحات، لكنه لا يصلح عطلًا داخليًا. يجمع منهج البناء الآمن هذه الممارسات دون وعد بمنتج خالٍ من الأخطاء؛ الاستقرار نتيجة دورة تحقق مستمرة لا زر واحد.

منهج بناء مشاريع Vibe Coding بلا ثغرات أو هلوسة: قواعد عملية وتقليل للمخاطر، لا ضمان انعدامها.

• إعلان Monitoring Agent — 22 أكتوبر 2026
• وثائق Monitoring Agent والإعدادات والتنبيهات
• مراقبة التطبيق المنشور والسجلات
• إعلان App Monitoring — 29 أبريل 2026
• تسعير Replit الحالي
• فوترة استخدام Agent
• إدارة الاستهلاك وحدود الإنفاق

راجعنا النصوص الرسمية بتاريخ التحرير. تفاصيل الوثائق الحية والأسعار قد تتغير، ولم نتحقق من إعدادات حساب Replit خاص أو ضمان أهلية جميع الخطط. بيانات البحث السعودية للكلمة Replit Monitoring Agent لم تتوفر، لذلك لا ندّعي حجم بحث أو سهولة ترتيب. العناوين تستخدم مصطلحات الميزة وأسئلة الاستخدام طبيعيًا. البيانات المنظمة وllms.txt يساعدان على وصف المحتوى ولا يضمنان استشهاد نماذج الذكاء الاصطناعي به.