كم كلفتك آخر عملية فشل صامت لديك؟

Feedback General
1

سير عمل ينتهي بنتيجة إيجابية بينما لم يحدث شيء — المواضيع مليئة بها. لكن ما لا أستطيع العثور عليه في أي مكان هو المال.

  1. متى حدثت آخر مرة — ما الذي كلفتك؟ استرجاع أموال، عميل فقدته، ساعات من البحث؟ ما نوع سير العمل الذي كان؟
  2. هل بنيت شيئاً من أجله لاحقاً، أم قررت أنه لا يستحق الوقت؟
  3. هل دفعت مقابل أداة في أي وقت خصيصاً للتقاط هذا؟ إذا كانت الإجابة نعم، أي أداة وكم دفعت. إذا كانت الإجابة لا، ما الذي كان يجب أن يكون صحيحاً؟

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

“لم تكلفني شيئاً ولن أدفع مقابل أداة للتقاط هذا” هي إجابة حقيقية — إذا كانت صحيحة، فهي الأكثر فائدة.

2

Twice, and neither was caught by monitoring I already had — an Error Trigger hooked to a workflow tells you a node threw, not that the run did nothing.

The expensive one: a nightly invoice → Sheets sync ran green for about a week and a half after an OAuth refresh started returning an empty item list. Nothing errored; the workflow just had zero rows to write. It surfaced when the client’s bookkeeper asked why the sheet stopped. Cost was roughly a day and a half of unbilled reconciling from a re-export, plus the part that actually stung — being the person who didn’t notice first.

What fixed it wasn’t a purchase. It was moving the assertion to the output: an IF node that fails when items.length === 0, and a heartbeat that pushes the last-successful-sync timestamp somewhere outside n8n, so a watchdog alerts if it goes stale rather than if a node throws. A cron’d curl to any dead-man’s-switch service does that for free.

The honest answer to your central question: the fix is a design habit, not a tool, so nobody pays for a tool. And on the consultancy point — retrofitting monitoring onto a client’s existing workflow is unbillable firefighting; sold up front as an observability line item it bills fine. Opposite answers because they’re describing different moments in the project.

3

The contradiction in the two answers you got is real, and I think it resolves on when the diagnosis happens, not on the workflow.

Billable: finding the silent-failure path before it fires, as a scoped deliverable. You read the workflow, name the three places it will fail quietly, and hand over a written document. That has a fixed price and a deadline, like any other deliverable.

Unbillable: finding it after it fires, in a “why is the data wrong” conversation. No scope, no end, and the client is already upset. That is firefighting, and it is usually absorbed.

Same defect, opposite economics.

A cost number from my own work, since you asked for money rather than theory. I audited the inbound-triage workflow I run, and found this: the IMAP trigger marks mail read on fetch. If anything later fails — classification, the draft call, the log write — the message is already read, never retried, never recorded. There is no error in the logs and nothing retries, because from n8n’s point of view the run finished.

What it costs: I do not know, and that is the point. It only surfaces when a customer says “I emailed you last Tuesday” and you cannot find the mail at all. So the “cost” of that class is unbounded in the worst case and zero in the good case — which is exactly why it never gets budgeted for.

Two things fixed it, both cheap:

  1. An assertion on the output, not just on errors. If the run produced zero rows, fail the run. Green means “wrote something”, not “did not throw”. The reply above about items.length is the right instinct.
  2. Write a received row before any AI call, and mark the mail read only after the log write succeeds. Then a failure leaves evidence instead of a hole.

On “did I pay for a tool”: I looked, did not find one that checks an exported workflow for these, and wrote a free script instead. It is public, it has the checks above among a dozen, and it is MIT — GitHub - Miss567/n8nwf-lint: Static reliability checks for exported n8n workflows - silent failures, missing retries, false threading claims. No dependencies, MIT. · GitHub . If it is useful, good; if you disagree with a rule, tell me and I would rather fix the rule than defend it.

The number I would most like to see in this thread: how many runs were green while writing zero rows. That is the honest metric, and almost nobody tracks it.