n8n Error Workflow: התראות כשל ל־Slack, לאימייל ול־WhatsApp

התשובה הקצרה: מחברים Error Handler לכל workflow שרוצים לנטר

כדי לקבל התראה כש־workflow ב־n8n נכשל, בונים workflow נפרד שמתחיל ב־Error Trigger, ובהגדרות כל workflow עסקי בוחרים אותו בשדה Error Workflow. הוא רץ כשהרצה אוטומטית של ה־workflow העסקי נכשלת, וגם workflow אחד כזה יכול לטפל בכמה workflows. n8n Docs: Handle errors gracefully, accessed October 2026 (נפתח בחלון חדש)

המדריך נולד מפוסט של n8n ב־X מ־9 בספטמבר 2026, שמכריז על Error Workflow כחינמי בכל התוכניות: n8n_io on X (נפתח בחלון חדש). הוא אינו תרגום של הפוסט. הוא נבנה מהתיעוד הרשמי של n8n ומהרצה שבנינו לצורך המדריך, והטענה על התמחור נבדקת בנפרד בסוף, בשאלות הנפוצות.

שאלה אחת דורשת זהירות כבר כאן: האם חובה לפרסם את ה־handler. עמוד התיעוד של Error Trigger אומר שאין חובה, n8n Docs: Error Trigger, accessed October 2026 (נפתח בחלון חדש) אבל חומר ההנחיה הרשמי של n8n לעבודה עם Error Workflow קובע שחובה לפרסם את ה־handler, אחרת ההגדרה נדחית. n8n skills repository: Error workflows reference, accessed October 2026 (נפתח בחלון חדש) בסביבת ההדגמה שלנו, ב־n8n 2.42.6, handler ששמרנו ולא פרסמנו לא הופעל, ולא נשלחה שום התראה. לכן מפרסמים את ה־handler, ובודקים בהרצה אוטומטית אחת שזה עובד אצלכם.

ערוץ התראה אחד מספיק. בהדגמה חיברנו שלושה, Slack, אימייל ו־WhatsApp, ובדקנו מה n8n שולח לנקודת קליטה מקומית. לא נשלחה הודעה לשירות אמיתי, ולכן בכל ערוץ תצטרכו לאשר שההודעה הגיעה אליכם. נוהל ניטור רחב יותר מתואר במדריך הניטור, ואת הכלי עצמו אפשר להכיר בעמוד n8n.

מה Error Workflow מכסה ומה הוא משאיר בחוץ

Error Workflow מגיב להרצה שנכשלה. n8n Docs: Handle errors gracefully, accessed October 2026 (נפתח בחלון חדש) הוא אינו מגיב לכל מצב שבו משהו השתבש בפועל: יש כשלים שנבלעים בתוך הרצה שמסתיימת בירוק, ויש מצבים שבהם אין הרצה בכלל.

בטייגרמדיה ראינו שני מקרים כאלה. הראשון: workflow גיבוי שהסתיים בהצלחה, כי צומת SSH החזיר קוד יציאה שאינו אפס כנתון רגיל ולא כשגיאה, ולכן Error Workflow לא הופעל. התיקון היה צומת בדיקה בסוף ה־workflow, שמכשיל את ההרצה אם ההצלחה לא אושרה. השני: תיקנו את ההרשאה של קריאת ההתראה עצמה. ה־workflow עדיין נכשל, כי הקריאה האמיתית לשירות החיצוני המשיכה להחזיר שגיאת הרשאה, אבל אחרי התיקון קריאת ההתראה הצליחה וההרצה נראתה כהצלחה.

יש גם חלופות ל־Error Workflow. Log Streaming מופיע בתיעוד כתכונת Enterprise, והוא שולח את האירוע n8n.workflow.failed ליעד חיצוני. n8n Docs: Log streaming, accessed October 2026 (נפתח בחלון חדש) ובהערות הגרסה מצוין שאם עדיין לא הוגדר שום Error Workflow במופע, n8n שולח לבעל ה־workflow מייל בכשל הייצור הראשון, פעם אחת בלבד לכל מופע. n8n Docs: Release notes, accessed October 2026 (נפתח בחלון חדש) מייל חד פעמי כזה אינו תחליף ל־handler משלכם.

מה צריך להכין לפני שמתחילים

ההכנה קצרה, אבל שלושה דברים ימנעו מכם להיתקע בבדיקה שלא מצליחה: workflow שאפשר להכשיל בלי לפגוע בנתוני אמת, ערוץ יעד שאתם יכולים לראות, וכתובת עורך נכונה לקישור שבהתראה. מי שמריץ n8n בשרת משלו ימצא הסבר נוסף במדריך האירוח העצמי.

1. פתחו מופע n8n שאתם הבעלים שלו או שאתם מנהלים אותו, בענן או באירוח עצמי.
2. הכינו workflow בדיקה שרץ אוטומטית, למשל מ־webhook, ושאינו שולח הודעה אמיתית ללקוח ואינו פותח הזמנה אמיתית.
3. בחרו ערוץ יעד שאתם בודקים בעצמכם: ערוץ Slack, או כתובת אימייל וחשבון SMTP לשליחה. n8n Docs: Send Email node, accessed October 2026 (נפתח בחלון חדש)
4. באירוח עצמי, הגדירו את N8N_EDITOR_BASE_URL לכתובת הציבורית של העורך. בהדגמה הקישור להרצה שבהתראה נבנה ממנה, וכתובת שגויה פירושה קישור שלא נפתח.

בונים Error Handler עם Error Trigger

ה־handler הוא workflow רגיל שהצומת הראשון בו הוא Error Trigger. הצומת מקבל פרטים על ה־workflow שנכשל ועל השגיאה כשאחד ה־workflows המקושרים נכשל. n8n Docs: Error Trigger, accessed October 2026 (נפתח בחלון חדש) התיעוד קובע שה־handler חייב להתחיל בו. n8n Docs: Handle errors gracefully, accessed October 2026 (נפתח בחלון חדש)

ה־handler שבנינו להדגמה כולל Error Trigger, צומת Code שמרכיב הודעה, ושלושה צמתי שליחה. בשלב הזה בונים רק את הצומת הראשון ושומרים. את שאר הצמתים מוסיפים בסעיפים הבאים.

1. צרו workflow חדש וקראו לו Error Handler.
2. הוסיפו את Error Trigger כצומת הראשון.
3. שמרו את ה־workflow.
4. השאירו אותו פתוח, כי בסעיף הבא מפרסמים אותו ובוחרים אותו בהגדרות ה־workflow העסקי.

מחברים את ה־handler ובודקים אם נדרש פרסום במופע שלכם

בהגדרות כל workflow עסקי יש שדה Error Workflow, שבו בוחרים workflow שיופעל כשה־workflow הנוכחי נכשל. n8n Docs: Workflow settings, accessed October 2026 (נפתח בחלון חדש) התיעוד של Error Trigger אומר שאין חובה לפרסם workflow שמכיל אותו. n8n Docs: Error Trigger, accessed October 2026 (נפתח בחלון חדש)

בהדגמה על n8n 2.42.6 ראינו התנהגות שונה ממה שכתוב בעמוד Error Trigger, והיא תואמת להנחיה הרשמית של n8n. n8n skills repository: Error workflows reference, accessed October 2026 (נפתח בחלון חדש) ה־handler נשמר ולא פורסם, הוגדר כ־Error Workflow, וההרצה הכושלת רשמה ביומן שה־workflow אינו פעיל ולא ניתן להריץ אותו. אחרי שפרסמנו את ה־handler, אותה תקלה הפעילה אותו. כשניסינו, דרך הגדרות ה־workflow, לבחור handler שלא פורסם, ההגדרה נדחתה בהודעה The selected error workflow has no published version. אנחנו לא יודעים להסביר את ההבדל מול עמוד התיעוד של Error Trigger, ולכן הצעד המומלץ הוא לפרסם את ה־handler ולבדוק בהרצה אוטומטית אחת.

1. פרסמו את Error Handler.
2. פתחו את ה־workflow העסקי, ובתפריט ... בחרו Settings.
3. בשדה Error Workflow בחרו Error Handler ושמרו.
4. הריצו הרצה אוטומטית כושלת אחת, כמו בסעיף על הבדיקה, וודאו שהתראה הגיעה.

n8n Error Handling: Get Email Alerts When Workflows Fail

שני המבנים של נתוני Error Trigger

הנתונים ש־Error Trigger מקבל אינם תמיד באותו מבנה. התיעוד מתאר מערך עם אובייקט אחד: execution עם id, url, retryOf, error שמכיל message ו־stack, lastNodeExecuted ו־mode, ולצדו workflow עם id ו־name. n8n Docs: Error Trigger, accessed October 2026 (נפתח בחלון חדש)

כשהשגיאה היא בצומת הטריגר של ה־workflow העסקי, המבנה שונה: פחות מידע ב־execution ויותר ב־trigger: יש בו error עם context, name, cause, timestamp, message ו־node, ולצד error גם mode. השדות execution.id ו־execution.url דורשים הרצה שנשמרה במסד הנתונים, והם חסרים כשהשגיאה בטריגר, כי ה־workflow בפועל לא רץ. השדה execution.retryOf מופיע רק בהרצה חוזרת של הרצה שנכשלה. התוצאה המעשית: הודעת ההתראה שלכם חייבת להתאים לשני המבנים, גם כשהקישור חסר.

בונים הודעה אחת עם צומת Code

שלושה ערוצים לא צריכים שלוש הודעות שונות. אפשר להרכיב הודעה אחת בצומת Code ולהעביר אותה לכל ערוץ, וכך כל שינוי בנוסח נעשה במקום אחד. הקוד שלמטה בודק איזה מבנה הגיע, שולף את שם ה־workflow, הצומת והשגיאה, ומשתמש בקישור להרצה רק כשהוא קיים.

הרצנו את הצומת בהרצה כושלת אמיתית של workflow ההדגמה, והוא הפיק הודעה עם שם ה־workflow, הצומת, הודעת השגיאה וקישור להרצה. הרצנו אותו גם על שתי דוגמאות המטען מהתיעוד, והמבנה של כשל בטריגר הניב את השורה אין קישור זמין להרצה במקום קישור שבור.

1. הוסיפו צומת Code אחרי Error Trigger.
2. הדביקו את הקוד שבהמשך בלי שינוי.
3. חברו את הפלט לצמתי השליחה שבסעיפים הבאים.
4. בדקו הכול בהרצה אוטומטית אחת, לא בהרצה ידנית.

// Build one alert text from the Error Trigger payload
const item = $input.first().json;
const wf = item.workflow?.name ?? 'workflow לא מזוהה';
const fromTrigger = item.trigger !== undefined;
const err = item.execution?.error ?? item.trigger?.error ?? {};
const node = item.execution?.lastNodeExecuted ?? err.node?.name ?? 'לא ידוע';
const link = item.execution?.url ?? 'אין קישור זמין להרצה';
const text = [
  `נכשל: ${wf}`,
  `צומת: ${node}`,
  `שגיאה: ${err.message ?? 'ללא הודעה'}`,
  `הרצה: ${link}`,
].join('\n');
return [{ json: { text, subject: `n8n נכשל: ${wf}`, workflow: wf, fromTrigger } }];

שולחים את ההתראה ל־Slack

לשליחה ל־Slack יש בתיעוד צומת ייעודי: במשאב Message קיימת פעולה Send, שמשתמשת בשיטת ה־API של Slack בשם chat.postMessage. n8n Docs: Slack node, accessed October 2026 (נפתח בחלון חדש) את השלבים כאן אנחנו לוקחים מהתיעוד, ולא הרצנו אותם מול סביבת Slack אמיתית.

מה שכן הרצנו הוא נתיב אחר: צומת HTTP Request ששלח בקשת POST בצורה של Slack incoming webhook, עם גוף JSON שמכיל את השדה text. נקודת הקליטה המקומית קלטה את ההודעה המלאה, כולל העברית. זה מוכיח מה n8n שולח, ולא שההודעה הופיעה בערוץ, ולכן בסביבה שלכם יש לוודא שהיא הגיעה.

1. הוסיפו צומת Slack אחרי צומת Code.
2. בחרו חיבור (credential) מתאים ל־Slack, ואת המשאב Message והפעולה Send.
3. בחרו את הערוץ, ובשדה ההודעה הכניסו את הביטוי {{ $json.text }}.
4. הריצו הרצה אוטומטית כושלת ובדקו בערוץ שההודעה הופיעה.

שולחים את ההתראה באימייל

צומת Send Email משתמש בחיבור SMTP, ומקבל כתובת שולח, כתובת נמען, נושא ופורמט (טקסט, HTML או שניהם). n8n Docs: Send Email node, accessed October 2026 (נפתח בחלון חדש) ההודעה שהרכבנו כבר מכילה נושא וגוף, ולכן ההגדרה קצרה.

בהדגמה שלחנו דרך SMTP לשרת קליטה מקומי. ההודעה הגיעה עם נושא בעברית שמקודד ב־UTF-8, וגוף הטקסט הכיל את ארבע השורות שהרכיב צומת Code. שרת ההדגמה לא שלח את המייל לתיבה אמיתית, ולכן אתם צריכים להשלים את הבדיקה מול תיבת הדואר שלכם. בצומת יש גם אפשרות להוסיף בסוף את המשפט This email was sent automatically with n8n. n8n Docs: Send Email node, accessed October 2026 (נפתח בחלון חדש)

1. הוסיפו צומת Send Email אחרי צומת Code.
2. בחרו או צרו חיבור SMTP.
3. מלאו כתובת שולח וכתובת נמען שאתם בודקים בעצמכם.
4. בשדה Subject הכניסו {{ $json.subject }}. בחרו פורמט Text, ובגוף ההודעה הכניסו {{ $json.text }}.
5. הריצו הרצה אוטומטית כושלת ובדקו שההודעה הגיעה לתיבה.

מוסיפים WhatsApp: מה הוכח ומה נשאר לבדוק

הדוגמה כאן היא בקשת HTTP לנקודת sendText של שרת Evolution API שאתם מפעילים בעצמכם. זה אינו מסלול ה־Cloud API הרשמי של Meta. מי שצריך מסלול רשמי, עם תבניות מאושרות והוכחת מסירה, ימצא אותו במדריך ה־Cloud API, ובהקשר של שיחה עם לקוחות יש גם את מדריך בוט ה־WhatsApp.

בהדגמה, צומת HTTP Request שלח בקשת POST עם כותרת apikey וגוף עם number ו־text, ונקודת קליטה מקומית קלטה אותם. זה כל מה שהוכח: צורת הבקשה. לא נשלחה הודעה לספק אמיתי, ולכן אין לנו ראיה למסירה, לניסיון חוזר או להתנהגות בזמן תקלה. הוכחה כזאת אפשר לקבל רק ממכשיר הבדיקה שלכם.

1. הוסיפו צומת HTTP Request אחרי צומת Code, בשיטת POST.
2. הכניסו ככתובת את הנתיב /message/sendText/<instance> על השרת שלכם.
3. שמרו את מפתח ה־apikey בחיבור מסוג Header Auth ב־n8n, ולא בתוך הצומת או הביטוי.
4. הכניסו את הביטוי שלמטה כגוף JSON, והחליפו את מספר הדוגמה במספר של מכשיר הבדיקה שלכם.
5. הריצו הרצה אוטומטית כושלת ובדקו במכשיר עצמו שההודעה הגיעה, ולא רק שהבקשה חזרה בהצלחה.

={{ JSON.stringify({ number: '972XXXXXXXXX', text: $json.text }) }}

יוצרים כשל מבוקר עם Stop and Error

כדי לבדוק את השרשרת צריך כשל שאפשר להפעיל לפי דרישה. הצומת Stop and Error נועד בדיוק לזה: הוא מכשיל הרצה בתנאי שבחרתם, וכך מפעיל את ה־Error Workflow. n8n Docs: Handle errors gracefully, accessed October 2026 (נפתח בחלון חדש) יש לו שתי פעולות: Error Message, שבה כותבים הודעת שגיאה, ו־Error Object, שבה מעבירים אובייקט JSON עם מאפייני השגיאה. n8n Docs: Stop and Error node, accessed October 2026 (נפתח בחלון חדש)

עשו זאת בעותק בדיקה בלבד. בעותק, הציבו את Stop and Error מיד אחרי הטריגר ולפני כל פעולה עסקית, או נתקו צמתים שעלולים לשלוח הודעה, לפתוח הזמנה או לשנות נתונים אמיתיים. לצורך הבדיקה השתמשו בהזמנה מזויפת ללא מספר טלפון, כדי שהתנאי ייכשל בכוונה.

בהדגמה, workflow עם webhook ותנאי בדק שלהזמנה יש טלפון, והענף השני הוביל ל־Stop and Error עם ההודעה Order 1043 has no phone number. הכשל הפעיל הרצה אחת של ה־handler, ושלוש הודעות הגיעו לנקודת הקליטה המקומית: הודעת Slack בצורת webhook, מייל, ובקשת sendText.

1. שכפלו את ה־workflow לעותק בדיקה.
2. הוסיפו תנאי שבודק שהשדה של הטלפון אינו ריק, ומהענף השני חברו את Stop and Error.
3. בשדה Error Message הכניסו הודעה שכוללת את מספר ההזמנה.
4. הגדירו את Error Handler כ־Error Workflow של העותק, ופרסמו את העותק.
5. שלחו הזמנה מזויפת לכתובת ה־webhook של העותק, כמו בפקודה שלמטה.

curl -X POST "$TEST_WEBHOOK_URL" \
  -H 'content-type: application/json' \
  -d '{"orderId":"1043","phone":""}'

בודקים בהרצה אוטומטית ומוודאים שההתראה הגיעה

הרצה ידנית מהעורך אינה בודקת את ה־handler. התיעוד קובע שאי אפשר לבדוק Error Workflow כשמריצים workflow ידנית, ושה־Error Trigger מופעל רק כשהרצה אוטומטית נכשלת. n8n Docs: Error Trigger, accessed October 2026 (נפתח בחלון חדש) לכן הבדיקה היא בקשה אמיתית לכתובת ה־webhook, כמו בסעיף הקודם.

בהדגמה ראינו את שני הצדדים. הזמנה בלי טלפון הסתיימה בהרצה שנכשלה, וה־handler רץ פעם אחת והסתיים בהצלחה. הזמנה עם טלפון הסתיימה בהצלחה ולא הפעילה את ה־handler. ההצלחה של ה־handler אינה הוכחה שההודעה הגיעה, ולכן הבדיקה כוללת גם את הערוץ שבחרתם.

1. שלחו הזמנה בלי טלפון לכתובת ה־webhook של עותק הבדיקה.
2. פתחו את הלשונית Executions של ה־workflow העסקי וודאו שנרשמה הרצה שנכשלה בצומת Stop and Error.
3. פתחו את Executions של Error Handler וודאו שרצה הרצה אחת שהסתיימה בהצלחה.
4. בדקו בערוץ שבחרתם, Slack, תיבת הדואר או מכשיר הבדיקה, שההודעה הגיעה עם שם ה־workflow והקישור.
5. שלחו הזמנה עם טלפון וודאו שלא רצה הרצה חדשה של ה־handler.

כשה־handler עצמו נכשל: מה ראינו בהדגמה ומה צריך לבדוק

מה קורה אם ה־handler עצמו נכשל? בהדגמה בדקנו מקרה אחד: הוספנו ל־handler צומת Stop and Error שנכשל, בלי Error Workflow נוסף. נרשמה הרצה אחת של ה־handler בסטטוס error, לא יצאה שום התראה על הכשל הזה, ולא נוצרה לולאה.

התצפית מתאימה למה שחומר ההנחיה הרשמי של n8n קובע: n8n לא מפעיל Error Workflow שוב כשה־Error Workflow עצמו נכשל, ולכן אין לולאה אינסופית, אבל הכשל הזה אינו מדווח לשום ערוץ. החומר ממליץ להשתמש בערוץ שונה מזה שבו משתמשים ה־workflows המנוטרים, למשל אימייל כשרובם שולחים ל־Slack. n8n skills repository: Error workflows reference, accessed October 2026 (נפתח בחלון חדש) אנחנו לא בדקנו מה קורה כשצומת Slack, צומת אימייל או הבקשה ל־WhatsApp נכשלים בגלל חיבור שפג תוקפו, ואין בידינו לומר מה יקרה אצלכם.

הצעה, לא תוצאה שבדקנו: התייחסו ל־handler כאל workflow ייצור לכל דבר. בדקו אותו מדי פעם על עותק בדיקה שלו, לא על ה־handler הפעיל, כדי לגלות אם ההתראה שותקת לפני שמשהו אמיתי נכשל.

מה Error Workflow לא רואה: כשלים בלי הרצת error

הטבלה מפרידה בין מה שהוכח בהדגמה, מה שראינו בעבודה שלנו, ומה שמבוסס על היגיון בלבד. השורה הראשונה היא נקודת ההתייחסות: המקרה שבו Error Workflow עובד. חומר ההנחיה הרשמי מוסיף שגם שגיאה שטופלה דרך יציאת שגיאה מחוברת בצומת, הרצה שנעצרה ידנית ו־workflow מושהה או לא פעיל אינם מפעילים אותו. n8n skills repository: Error workflows reference, accessed October 2026 (נפתח בחלון חדש)

בהדגמה הגדרנו צומת HTTP Request ליעד שאינו עונה, כשההגדרה On Error מוגדרת ל־Continue. ההרצה הסתיימה בסטטוס success, ה־handler לא רץ ולא יצאה התראה. זה אחד ממקרי ההרצה הירוקה שמסתירה כשל. שני האחרים הם אלה שתיארנו בסעיף השני: קוד יציאה שחוזר כנתון, ושליחת התראה שהצליחה והסתירה כשל קודם בהרצה.

שומרים נתוני הרצה וקישור שאפשר לפתוח

שני דברים הופכים התראה לשימושית: יש הרצה שמורה שאפשר לפתוח, והקישור אליה נפתח. הגדרות שמירת ההרצות קיימות לכל workflow בנפרד, ביניהן שמירת הרצות כושלות. n8n Docs: Workflow settings, accessed October 2026 (נפתח בחלון חדש) באירוח עצמי התיעוד מציג ברירות מחדל כמו EXECUTIONS_DATA_SAVE_ON_ERROR=all, שהן הגדרות סביבה שאפשר לשנות, ולכן בדקו מה פעיל אצלכם. n8n Docs: Executions environment variables, accessed October 2026 (נפתח בחלון חדש)

בלי הרצה שמורה אין execution.id ו־execution.url, וקישור להרצה לא יהיה בהתראה. n8n Docs: Error Trigger, accessed October 2026 (נפתח בחלון חדש) בהדגמה הקישור נבנה מכתובת העורך שהוגדרה ב־n8n, ובאירוח עצמי היא חייבת להיות הכתובת הציבורית הנכונה.

שדות ההתראה בקוד שלמעלה הם שם ה־workflow, הצומת, השגיאה והקישור. הצעות נוספות, כמו דרגת חומרה, אחראי לכל workflow או איחוד כפילויות, אינן חלק ממה שבדקנו, ולכן אל תסתמכו על מנגנון כזה בלי לבנות ולבדוק אותו בעצמכם.

שאלות נפוצות לפני העלייה לייצור

השאלות כאן עוסקות בתמחור, בפרסום ובמה שלא בדקנו. כל תשובה מפרידה בין מה שמופיע בתיעוד לבין מה שראינו בהדגמה.

רשימת בדיקה לפני שסומכים על ההתראות

הרשימה שלמטה מסכמת את הבדיקות שהמדריך הראה. מי שמעדיף שמישהו יבנה את זה בשבילו ימצא פרטים בשירותי n8n.

• ה־handler פורסם, ובדקתם אצלכם בהרצה אוטומטית שהוא רץ כשה־workflow נכשל.
• ה־handler נבחר בשדה Error Workflow בהגדרות כל workflow שרוצים לנטר.
• קוד ההתראה מטפל בשני מבני הנתונים של Error Trigger וגם במצב שבו חסר קישור להרצה.
• בדקתם בערוץ עצמו, Slack, תיבת דואר או מכשיר, שההודעה הגיעה.
• הכשלתם workflow בדיקה בכוונה והתראה אחת יצאה, ובהזמנה תקינה לא יצאה אף התראה.
• בדקתם כשל בתוך עותק בדיקה של ה־handler, לא ב־handler הפעיל, וידעתם מה קורה אצלכם כשהוא שותק.
• בדקתם גם את המקרים שאין בהם הרצת error: On Error על Continue, וקוד יציאה שחוזר כנתון.
• באירוח עצמי, כתובת העורך הציבורית נכונה והקישור שבהתראה נפתח.