أولئك الذين يديرون سير عمل n8n للعملاء — كيف تكتشفون متى يحدث خلل ما؟

Feedback General
1

صف المشكلة/الخطأ/السؤال

أقوم بتشغيل عمليات أتمتة في n8n لعدد قليل من العملاء، والجزء الذي يسبب لي التوتر ليس البناء — بل عدم معرفتي متى ينقطع شيء ما بهدوء.

ما رسالة الخطأ (إن وجدت)؟

يرجى مشاركة سير عملك

(حدد العُقد على لوحتك واستخدم اختصارات لوحة المفاتيح CMD+C/CTRL+C و CMD+V/CTRL+V لنسخ ولصق سير العمل.)

شارك الإخراج الذي أرجعته العُقدة الأخيرة

معلومات عن إعداد n8n الخاص بك

  • إصدار n8n:
  • قاعدة البيانات (الافتراضي: SQLite):
  • إعداد n8n EXECUTIONS_PROCESS (الافتراضي: own, main):
  • تشغيل n8n عبر (Docker, npm, سحابة n8n, تطبيق سطح المكتب):
  • نظام التشغيل:
إعجاب واحد (1)
2

نص عادي

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

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

n8n به عقدة `Error Trigger` مخصصة. عند إعدادها في سير عمل مستقل، تعمل كمستمع عام. في أي وقت *أي* سير عمل نشط في مثيل n8n بأكمله يفشل، يمسك هذا المحفز به ويسحب جميع البيانات الوصفية (اسم سير العمل، العقدة التي فشلت، رسالة الخطأ، معرف التنفيذ).

إليك قالب جاهز للاستخدام لمخطِّط إخطارات الأخطاء العام. فقط انسخ هذا JSON والصقه في سير عمل جديد وفارغ:

```json
{
  "nodes": [
    {
      "parameters": {},
      "type": "n8n-nodes-base.errorTrigger",
      "typeVersion": 1,
      "position": [240, 240],
      "id": "2498e94e-d00d-4054-9988-518201a052e4",
      "name": "Error Trigger (Catch All)"
    },
    {
      "parameters": {
        "mode": "json",
        "json": {
          "workflowName": "={{ $json.context.workflow.name }}",
          "workflowId": "={{ $json.context.workflow.id }}",
          "executionId": "={{ $json.context.execution.id }}",
          "errorNodeName": "={{ $json.error.context.node.name }}",
          "errorMessage": "={{ $json.error.message }}",
          "timestamp": "={{ new Date().toISOString() }}"
        },
        "options": {}
      },
      "type": "n8n-nodes-base.set",
      "typeVersion": 1,
      "position": [480, 240],
      "id": "e914041a-a131-4a4b-8526-a05d6888c3a5",
      "name": "Format Error Data"
    },
    {
      "parameters": {
        "fromEmail": "n8n@yourdomain.com",
        "toEmail": "youremail@yourdomain.com",
        "subject": "🚨 n8n Workflow Failed: {{ $json.workflowName }}",
        "text": "مرحباً،\n\nفشل سير عمل n8n بشكل غير متوقع.\n\n----------------------------------------\nاسم سير العمل: {{ $json.workflowName }}\nمعرف سير العمل: {{$json.workflowId }}\nمعرف التنفيذ: {{ $json.executionId }}\nالعقدة الفاشلة: {{$json.errorNodeName }}\nرسالة الخطأ: {{ $json.errorMessage }}\nالطابع الزمني: {{$json.timestamp }}\n----------------------------------------\n\nيرجى التحقق من تنفيذات مثيل n8n الخاص بك.",
        "options": {}
      },
      "type": "n8n-nodes-base.emailSend",
      "typeVersion": 1,
      "position": [720, 240],
      "id": "766a2673-8181-4200-a07c-95c52c035661",
      "name": "Email Send (Error Alert)"
    }
  ],
  "connections": {
    "Error Trigger (Catch All)": {
      "main": [
        [
          {
            "node": "Format Error Data",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Format Error Data": {
      "main": [
        [
          {
            "node": "Email Send (Error Alert)",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  }
}

كيفية استخدامه:

  1. الصق هذا في سير عمل جديد.

  2. افتح عقدة Email Send (أو استبدلها بعقدة Slack/Discord إذا فضلت تنبيهات الدردشة).

  3. قم بتوصيل بيانات اعتماد بريدك الإلكتروني وقم بتعيين toEmail.

  4. فعّل سير العمل هذا.

الآن، لا تقلق. إذا فشل أي شيء بصمت، ستتلقى فوراً بريداً إلكترونياً يحتوي على التفاصيل الدقيقة لما انقطع وأين!

4

Following up on this since a few people asked how I ended up detecting these.

The short version: n8n’s execution status alone misses an entire class. A node set to continue-on-fail records its error inside data.resultData.runData[nodeName][].error while the run still reports success. You need includeData=true to see it at all.

I wrote up what I found, including two classification mistakes that took me a while to notice — one of them being that a dead Google credential often surfaces with no HTTP code at all: Why n8n says a workflow succeeded when it didn't — Okum

If anyone has hit a failure shape that doesn’t fit, I’d like to hear it.

إعجاب واحد (1)
5

The failure the Error Trigger can’t see is the one that actually burns you: a workflow that never runs. If a trigger silently dies or Cloud auto-deactivates after a hard crash, nothing errors, so nothing alerts.

I’d pair the global Error Trigger with one heartbeat workflow on a schedule that hits the public API per client flow — GET /api/v1/executions?workflowId=… and compare the newest startedAt against the window that flow is supposed to run in, plus GET /api/v1/workflows/{id} to confirm active is still true. One catches loud failures, the other catches silence.

6

The silence case is the one I keep coming back to as well, and your split is right — one catches loud failures, the other catches absence.

One cause of it that surprised me: a workflow can be deployed and simply never activate, with no error anywhere. I hit this with form and webhook triggers — deploy the same template to a second client and both copies claim the same URL path, so n8n refuses to activate the second one. It shows as saved and looks fine in the list, but it has never run once. GET /api/v1/workflows/{id} and checking active is the only thing that catches it, exactly as you said.

Worth checking that alongside the heartbeat, since a workflow that never activated has no startedAt to compare against at all — there’s no history to notice a gap in.

Have you found a reliable window per workflow, or do you set the expected interval by hand per client? That’s the part I haven’t solved — a flow that runs hourly and one that runs on a form submission need very different definitions of “too quiet.”