بدأ جدول فوترة Cloudflare Workflows للخطوات والتخزين في 10 أغسطس 2026. المنتج نفسه متاح على خطتي Workers Free وPaid، وأصبح Generally Available منذ أبريل 2025، لكن كلفة workflow لم تعد مجرد طلب ووقت CPU. يجب الآن حساب أربعة أبعاد: invocations، وCPU، وsteps، وحجم الحالة المخزنة عبر الزمن.
هذا لا يعني أن Workflows أصبح باهظاً لكل مشروع. الخطة المجانية تضع allowances واضحة ولا تخصم رسوماً فوقها، والخطة المدفوعة تتضمن حصة شهرية قبل overage. الخطر الحقيقي هو تصميم مسار طويل بلا قياس، والاحتفاظ بحالة كبيرة بعد اكتمال العمل، ثم اكتشاف الفاتورة بعد أن تضاعفت الأحداث أو retries في الإنتاج.
جدول الأسعار الرسمي وإعلان فوترة الخطوات والتخزين
افصل أبعاد الفاتورة الأربعة
1. Requests أو invocations
كل إنشاء Workflow instance هو invocation. في Workers Free تشترك Workflows في حد 100,000 طلب يومياً. في Workers Paid توجد 10 ملايين request شهرياً ضمن الخطة، ثم 0.30 دولار لكل مليون إضافي. الـ subrequests التي يجريها Workflow لا تضاف كرسوم request مستقلة في هذا البند، لكنها تظل خاضعة للحدود التشغيلية.
2. CPU time
يدفع Workflow سعر Workers Standard للـ CPU. Paid يتضمن 30 مليون CPU ms شهرياً ثم 0.02 دولار لكل مليون إضافي. Free يسمح 10 ms CPU لكل invocation. وقت انتظار API أو step.sleep أو توقف workflow ليس CPU time، ولذلك يمكن لمسار يستغرق أياماً wall-clock أن يستهلك CPU قليلاً إذا كان معظم الوقت انتظاراً.
3. Steps
Free يتضمن 3,000 خطوة يومياً. Paid يتضمن 500,000 خطوة شهرياً، ثم 0.80 دولار لكل 100,000 إضافية. خطوة صغيرة ما زالت step، لذلك عشرون خطوة لكل طلب عميل تعني مليوني خطوة عند 100,000 طلب. وتوضح صفحة السعر أن rollback handlers وretries لا تدخل في step count المحتسب، لكن يجب قياسها لأنها قد ترفع CPU ووقت التنفيذ والأخطاء التشغيلية.
4. Storage
Free يتضمن 1 GB، وPaid يتضمن 1 GB-month ثم 0.20 دولار لكل GB-month إضافي. القياس يحسب حالة instances الجارية والمتوقفة والمنتظرة والمكتملة والتي انتهت بخطأ. تحتفظ الخطة المجانية بالحالة افتراضياً 3 أيام، والمدفوعة 30 يوماً. بقاء نتيجة كبيرة بعد نجاح workflow قد يكلف أكثر من التنفيذ نفسه.
ابنِ نموذج تكلفة قبل الكود
اكتب أربع معادلات في spreadsheet أو dashboard:
monthly_invocations = business_events × retry_or_replay_factor
monthly_steps = monthly_invocations × average_steps
step_overage = max(0, monthly_steps - 500000) / 100000 × $0.80
storage_overage = max(0, average_GB_month - 1) × $0.20ثم أضف request وCPU overage. لا تستخدم الحد الأقصى النظري لكل خطوة كتقدير وحيد. استخرج المتوسط وP95 من test data، وأضف سيناريو burst وفشل مزود خارجي وإعادة تشغيل يدوية.
مثال: نظام onboarding ينشئ 80,000 instance شهرياً بمتوسط 9 خطوات. هذا يساوي 720,000 خطوة، أي 220,000 فوق الحصة. عند التقريب بوحدات 100,000، تقدير step overage يقارب 1.76 دولار وفق المعدل المنشور، قبل الطلبات وCPU والتخزين. الرقم ليس فاتورة نهائية، لكنه يكشف أن تغيير 9 خطوات إلى 14 يهم أكثر من تحسين بضعة أسطر في خطوة واحدة.
لا تنس تكلفة النظام الخارجي. استدعاء LLM أو بريد أو دفع أو R2 قد يكلف خارج Workflows. اجمع تكلفة outcome كاملة: Cloudflare، المزود، retries، support، والتعويض عن العملية الفاشلة.
متى تكون الخطوة مفيدة ومتى تكون ضجيجاً؟
الخطوة الجيدة تمثل boundary تحتاج durability أو retry مستقل أو دليل تشغيل. أمثلة: حجز payment intent، كتابة order، إرسال إشعار، أو انتظار موافقة بشرية. تقسيم كل تحويل بيانات صغير إلى step منفصلة يزيد العد والـ state من دون حماية مفيدة.
في المقابل، دمج كل العملية في خطوة واحدة قد يعيد تنفيذ side effects عند retry ويصعب التشخيص. استخدم هذا السؤال: إذا فشلت هذه الوحدة، هل أريد إعادة تشغيلها وحدها مع output محفوظ؟ إذا كانت الإجابة نعم، فالخطوة غالباً لها قيمة. إذا كانت مجرد mapping داخل الذاكرة، أبقها داخل step الحالية.
سمِّ الخطوات بأسماء أعمال ثابتة مثل reserve_inventory وsend_receipt، لا step_3. الأسماء الواضحة تجعل GraphQL analytics وlogs مفيدة عند مقارنة stepCount ومسار الفشل.
التخزين: أصل الفاتورة الصامتة
تخزن Workflows outputs والحالة كي تستأنف بعد الفشل. هذا هو سبب فائدتها، لكنه يجعل payload design قرار تكلفة وخصوصية. لا تعِد binary كبيراً من step إذا كان R2 object key يكفي. لا تحفظ نسخة كاملة من سجل العميل في كل مرحلة إذا كان identifier وversion يحققان الاستعادة.
تسمح Workers API بتحديد retention عند إنشاء instance:
await env.ORDER_WORKFLOW.create({
id: orderId,
params: { orderId },
retention: {
successRetention: "1 day",
errorRetention: "7 days",
},
});استخدم مدة أقصر للنجاح إذا كانت الأدلة الدائمة موجودة في قاعدة النظام، ومدة أطول للأخطاء إذا احتاجها التحقيق. لا تقلل retention قبل تحديد متطلبات التدقيق والدعم والنزاع. الحذف لتوفير التكلفة يجب ألا يمحو سجلاً قانونياً أو مالياً يحتاجه العمل.
حدود تؤثر في التصميم
تسمح Paid افتراضياً بـ 10,000 خطوة لكل instance ويمكن رفعها إلى 25,000، بينما Free محدود بـ 1,024. الحالة القصوى 100 MB في Free و1 GB في Paid. نتيجة غير stream لكل step محدودة بـ 1 MiB، وevent payload أيضاً 1 MiB. CPU في Paid افتراضياً 30 ثانية لكل خطوة ويمكن رفعه إلى 5 دقائق، بينما wall-clock للخطوة قد يكون غير محدود عند انتظار I/O.
كما أن Workflows لا تعمل داخل Workers for Platforms namespaces وفق صفحة limits الحالية. إذا كنت تبني SaaS متعدد المستأجرين يشغّل كود العملاء، راجع Dynamic Workflows وقيوده بدلاً من افتراض أن binding العادي سينتقل إلى namespace.
هذه حدود تقنية وليست أهدافاً. Workflow يصل إلى 25,000 خطوة أو 1 GB حالة يحتاج مراجعة معمارية قبل طلب رفع limits.
قائمة تنفيذ ومراقبة
- سمِّ business event الذي يبدأ كل instance وحدد idempotency key.
- ارسم الخطوات مع side effect وretry وcompensation لكل واحدة.
- قدر invocations وaverage/P95 steps وCPU وحجم output والاحتفاظ.
- اجعل state تحتوي identifiers ونتائج صغيرة، وانقل الملفات الكبيرة إلى R2.
- اضبط
successRetentionوerrorRetentionحسب سياسة العمل. - ضع budget alerts وفصّل Free/Paid وبيئة production عن test.
- اسحب
stepCountوحالات النجاح والخطأ من GraphQL Analytics API. - اختبر فشل API بعد side effect وتأكد أن retry لا يكرر الدفع أو البريد.
- راقب التكلفة لكل outcome ناجح، لا التكلفة لكل invocation فقط.
- راجع التقدير بعد أول 7 و30 يوماً من حركة حقيقية.
المخاطر والتوفر والتوافق
- Workflows GA ومتاحة في Workers Free وPaid. لا تعرض الوثائق قيد دولة منفصلاً، لكن حساب Enterprise يخضع للعقد والامتثال الخاص به.
- Free لا يفرض رسوماً إضافية على الخطوات أو التخزين بعد allowance، لكنه يصل إلى limits وقد يفشل حفظ state عند بلوغ حد التخزين.
- الأسعار بالدولار المنشور وقد تدخل الضرائب أو تحويل العملة أو عقد Enterprise خارج هذا الجدول.
- الأسعار والـ allowances قابلة للتغيير. ثبّت تاريخ نموذج التكلفة وأعد مراجعته قبل عقد سعر ثابت مع العميل.
- idle time لا يستهلك CPU، لكنه قد يحتفظ بحالة قابلة للفوترة.
- retry الآمن يحتاج idempotency على النظام الخارجي. دوام Workflow لا يجعل payment API أو CRM idempotent تلقائياً.
توصية عملية
لا تهرب من Workflows بسبب بند step جديد، ولا تستخدمها لكل background task لأنها مريحة. استخدمها عندما تحتاج durability، انتظاراً طويلاً، retries مستقلة، أو مساراً يمكن تفسيره. في مهمة قصيرة بلا حالة، Queue أو Worker عادي قد يكون أبسط وأرخص تشغيلياً.
عند تسعير نظام أعمال لعميل، اعرض assumptions بوضوح: عدد الأحداث، متوسط الخطوات، retention، حجم state، وموفرات الخارج. ضع allowance للمجهول، ثم راجع السعر بعد بيانات حقيقية. التصميم الجيد هنا ليس الأقل steps بأي ثمن، بل أقل steps تحقق الاستعادة والتدقيق من دون تخزين زائد أو side effects مكررة.
المصادر وتاريخ المراجعة
- أسعار Workflows الحالية وأبعاد الفوترة
- سجل تغيير فوترة الخطوات والتخزين
- حدود Free وPaid
- خيارات retention عند إنشاء instance
- إعلان Generally Available
- تمت مراجعة حالة المنتج والأسعار والحدود والتوفر في 29 أغسطس 2026.