ניטור

מסך הניטור של Joryio מאפשר להגדיר התראות שיופעלו כשמדד שחשוב לכם חוצה סף - תעבורת ה־API הנכנסת, הודעות ה־Webhook ש־Joryio שולחת מהמסעות שלכם, אירועי הלקוחות שהאפליקציה וה־SDK שלכם עוקבים אחריהם או שיעורי יכולת המסירה שלכם (החזרות, תלונות ומסירה). כל התראה עוקבת אחר מדד אחד, בודקת אותו מדי דקה ומודיעה לכם באימייל או ב־Webhook כשהוא עובר ממצב תקין למצב מופעל.

פתחו את Settings → Logs & Monitoring בלוח הבקרה כדי לנהל התראות ולבדוק הפעלות קודמות.

מרכז Logs & Monitoring

הניטור נמצא במרכז Logs & Monitoring המאוחד, שאליו מגיעים דרך פריט יחיד בסרגל הצד. הסרגל השמאלי במרכז מקבץ ארבעה אזורים:

אזור	מה הוא מציג
Alerts	כל כללי ההתראות בסביבת העבודה, מצב ההפעלה שלהם ופעולות מהירות (Snooze / Pause / Edit / Delete / Duplicate).
History	יומן להוספה בלבד של כל מעבר של התראה אל מצב מופעל או ממנו. משמש לסקירה לאחר תקרית.
Error logs	שגיאות מסירה ועיבוד בכל הערוצים, לאבחון שליחות שנכשלו.
Audit	פעולות מנהל, שגיאות משלוח ואירועי אימות - ראו יומן ביקורת.

דף זה עוסק ב־Alerts וב־History (יכולת ההתראות). הפעלות ופתרונות של התראות מגיעים גם לפעמון בכותרת לוח הבקרה, עם מצב קריאה אישי לכל אדם (ראו התראות), כך שאין צורך להשאיר את המרכז פתוח כדי להבחין בתקרית.

יצירת התראה

לחצו על + New alert בדף Alerts. טופס ההתראה החדשה הוא אשף בן שלושה שלבים עם סרגל צד קבוע שעוקב אחר ההתקדמות:

שלב	כותרת	מה מגדירים
1	Metric - מה לנטר	בחרו תבנית להתחלה מהירה (או בנו התראה בעצמכם), תנו להתראה שם ובחרו כיוון ומדד.
2	Condition - מתי היא מופעלת	בחרו השוואה מוחלטת או השוואת שינוי, הגדירו את הסף, צמצמו את ההיקף לפי הצורך וצפו בתצוגה מקדימה חיה.
3	Notify - מי יקבל הודעה	בדקו את הסיכום, בחרו את ערוץ ההתראה (אימייל או Webhook) והגדירו זמן צינון ומצב הפעלה.

אפשר לחזור דרך סרגל הצד לכל שלב שהושלם. ההתקדמות באמצעות Next מותנית בהשלמת השדות - אי אפשר להתקדם מעבר לשלב 1 עד שלהתראה יש שם, והכותרת התחתונה מציגה תג מצב חי (Would fire now / Healthy / Paused) החל משלב 2.

Step 1 - Metric

התחילו מתבנית

תבניות מוכנות מראש מכסות את התרחישים הנפוצים ביותר בשלוש קבוצות. בחירת תבנית ממלאת מראש את כל השלבים - עדיין אפשר לשנות כל דבר לפני השמירה. לחצו על Clear כדי לחזור לטופס ריק.

Inbound - קריאות API אל Joryio:

תבנית	מופעלת כש
Integration silent failure	סך הקריאות יורד ב־80% לפחות לעומת השעה הקודמת. מזהה פריסה ששברה את האינטגרציה.
Auth broken	יותר מ־100 תגובות 401 Unauthorized בתוך 5 דקות. מזהה פריסה שביטלה את תוקף מפתח ה־API.
Server rejecting payloads	יותר מ־100 תגובות 5xx בתוך 5 דקות. בדרך כלל פירוש הדבר שמבנה הבקשה השתנה ו־Joryio כבר אינה יכולה לנתח אותו.
Traffic spike	סך הקריאות עולה ב־200% לעומת השעה הקודמת. מזהה סקריפט שיצא משליטה או זינוק בלתי צפוי.

Outbound - הודעות Webhook ש־Joryio שולחת מהמסעות שלכם:

תבנית	מופעלת כש
Webhook endpoint failing	יותר מ־50 תגובות 5xx למסירות Webhook בתוך 5 דקות. נקודת הקצה אינה זמינה או שהנתיב כבר אינו קיים.
Webhook stopped firing	מסירות ה־Webhook יורדות ב־90% לפחות לעומת השעה הקודמת. ייתכן שהמסע מושהה, שהקהל התרוקן או שהתור תקוע.

Events - ירידות במשפך של האירועים שאתם עוקבים אחריהם:

תבנית	מופעלת כש
Purchase funnel drop	מספר אירועי purchase_complete יורד ב־50% לפחות לעומת אותו יום בשבוע שעבר.
Add-to-cart drop	מספר אירועי add_to_cart יורד ב־30% לפחות לעומת אותה שעה בשבוע שעבר.
Signup drop	מספר אירועי signup יורד ב־50% לפחות לעומת אותו יום בשבוע שעבר.
Active user drop	מספר המשתמשים הייחודיים שמפעילים אירועים יורד ב־40% לפחות לעומת אותו יום בשבוע שעבר.

למה "שבוע שעבר"?

תבניות האירועים משוות מול אותו חלון בשבוע שעבר ולא מול החלון שקדם לו מיד. לאירועי לקוחות יש עונתיות שבועית ושעתית חזקה - ירידה ביום ראשון בלילה היא רגילה, לא תקרית - ולכן השוואה לשעה הקודמת עלולה ליצור התראות שווא ללא הרף. ראו השוואה אל בהמשך.

Deliverability - שיעורי תקינות המסירה בכל הערוצים:

תבנית	מופעלת כאשר
High bounce rate	שיעור ההחזרות מעל 5% ב־24 השעות האחרונות. עשוי להעיד על בעיה באיכות הרשימה או במוניטין השולח.
High complaint rate	שיעור התלונות מעל 0.1% ב־24 השעות האחרונות. עוזר להישאר מתחת לסף הספאם של ספקי שירותי האינטרנט.
Low delivery rate	שיעור המסירה יורד מתחת ל־95% ב־24 השעות האחרונות. פחות הודעות מגיעות לתיבות הדואר הנכנס.

פרטים בסיסיים

שדה	תפקיד
Alert name	חובה. מוצג בלוח הבקרה, בנושא של אימייל ההתראה או במטען ה־Webhook וביומן History. אי אפשר להתקדם לשלב 2 עד למילוי השדה.
Description	אופציונלי. מוצג לחברי צוות שמעיינים בהתראות ובגוף האימייל, כדי שהכוננים יבינו במה עוסקת ההתראה.

כיוון

בחרו באיזה זרם ההתראה תצפה:

• Inbound API - סופר בקשות שנכנסות אל ה־REST API של Joryio (לדוגמה, כשהשרתים שלכם קוראים ל־POST /events).
• Outbound webhooks - סופר מסירות Webhook שיוצאות מ־Joryio (נשלחות מצומת Webhook במסע משתמש).
• Events - סופר את אירועי הלקוחות שה־SDK או האפליקציה שלכם עוקבים אחריהם כשהם מגיעים ל־Joryio. הוא עוקב אחר מספר האירועים שנשמרו, לא אחר מספר קריאות ה־API הנכנסות - המספרים שונים כאשר Joryio מקבלת קריאה אך דוחה את המטען (מקרה כזה שייך ל־Inbound API).
• Deliverability - עוקב אחר שיעורי תקינות המסירה (החזרות, תלונות, מסירה וכדומה), הנמדדים כאחוז מההודעות שנשלחו בחלון המבט לאחור. הוא מכסה כל ערוץ שיכול לדווח על המדד, מאוחד כממוצע משוקלל לפי כמות השליחה: שיעור מסירה בכל חמשת הערוצים, שיעור הסרה באימייל וב-SMS, החזרות ותלונות באימייל, הערוץ היחיד שיש לו אותן. בעבר הוא נמדד באימייל בלבד, ולכן סביבת עבודה ששולחת בעיקר SMS או Push עקבה אחרי שיעור שהתעבורה שלה בקושי תרמה לו. בניגוד לכיוונים המבוססים על ספירה, יכולת המסירה פועלת תמיד ב־Absolute mode (סף על השיעור) ואין לה מסנן היקף - היא מכסה את כל ההודעות שנשלחו מסביבת העבודה.

תוויות המדדים שבהמשך משתנות בהתאם לכיוון שתבחרו.

Metric

נכנס / יוצא:

מדד	מה הוא מודד	מתי להשתמש
Calls / Deliveries by response code	מספר הקריאות לאחר סינון לפי קודי מצב HTTP שתבחרו.	התראות על שיעורי שגיאות (401, 429, 5xx).
Total calls / deliveries	ספירת כל הקריאות ללא תלות בקוד.	"האם האינטגרציה הפסיקה לפעול?" / "האם יש קפיצת תעבורה?"
Requests / Deliveries per second	תפוקה ממוצעת בחלון ההערכה.	התראות קיבולת לפי מפתח או נקודת קצה.

אירועים:

מדד	מה הוא מודד	מתי להשתמש
Event count	מספר האירועים מסוג יחיד (לדוגמה purchase_complete).	התראת הירידה הקלאסית במשפך - שלבו עם מצב Change ועם אותו חלון בשבוע שעבר.
Total events	מספר כל האירועים מכל שמות האירועים.	מזהה מצב שבו ה־SDK משתתק לחלוטין (פריסה ששברה את האתחול או אפליקציה שקרסה בקרב Cohort מסוים).
Unique users	מספר המשתמשים הייחודיים שמפעילים את האירוע שנבחר (או אירוע כלשהו, אם לא נבחר שם אירוע).	מבחין בין בעיות בצד הקהל לבין זינוקים של משתמשים פעילים במיוחד - עדיף מספירה גולמית.

Deliverability (תמיד מצב מוחלט, הסף הוא אחוז; בחרו חלון מבט לאחור של 1h / 4h / 24h / 7d):

מדד	מה הוא מודד	מתי להשתמש
Bounce rate	הוחזרו ÷ נשלחו.	המדד המרכזי להגעה לתיבת הדואר הנכנס - התריעו מעל ~2–5%.
Complaint rate	תלונות ספאם ÷ נשלחו.	ספקי תיבות דואר מגבילים משלוחים מעל ~0.1–0.3% - התריעו מוקדם.
Hard / Soft bounce rate	החזרות קבועות או זמניות ÷ נשלחו.	מאפשר להפריד החזרות קשות שפוגעות במוניטין מהחזרות רכות וזמניות.
Unsubscribe rate	הסרות מרשימת התפוצה ÷ נשלחו.	מזהה עייפות מהתוכן או מתדירות השליחה.
Delivery rate	נמסרו ÷ נשלחו.	השתמשו באופרטור Below כדי להפעיל את ההתראה כשהמסירה יורדת מתחת לרף תקין (למשל < 95%).

כל אחד מהשיעורים למעלה מאוחד על פני הערוצים שמפיקים אותו, משוקלל לפי כמות השליחה של כל ערוץ, כדי שערוץ בעל נפח נמוך לא יטלטל את ההתראה לבדו.

הערה

התראות על יכולת המסירה דורשות נפח כדי להיות משמעותיות: אם לא נשלחו הודעות בחלון המבט לאחור, ההתראה לא תופעל (כך שהתראת delivery rate < 95% לא תיצור התראת שווא בלילה שקט).

קודי תגובה (נכנס/יוצא, במידת הצורך)

כאשר המדד הוא by response code, בחרו אילו קודי מצב HTTP ייספרו. הבורר מקבץ את הקודים כך:

• Buckets - 2xx, 4xx, 5xx או כל הקודים.
• Success - 200, 201, 202, 204.
• Client errors - 400, 401, 403, 404, 422, 429.
• Server errors - 500, 502, 503, 504.

אפשר לשלב קבוצות וקודים מסוימים (לדוגמה "5xx או 429").

שלב 2 - תנאי

השוואה ל-

שני מצבי הערכה:

מצב	התנהגות
Absolute	מופעלת כשהמדד חוצה ערך קבוע במשך חלון רציף. "יותר מ־100 שגיאות בתוך 5 דקות."
Change over time	מופעלת כשהמדד עולה או יורד בשיעור מסוים (או בכמות מוחלטת) לעומת חלון קודם. "מספר הקריאות ירד ב־80% לעומת השעה הקודמת."

שדות מצב Absolute:

• Above / Below - כיוון הסף.
• Threshold value - הערך המספרי שהמדד חייב לחצות.
• For X duration - המדד חייב להישאר מעבר לסף במשך כל החלון לפני שההתראה תופעל. אפשרויות: 1m, 5m, 10m, 30m, 1h.

שדות מצב Change:

• Increased by / Decreased by - כיוון השינוי.
• Threshold value - האחוז או הכמות המוחלטת של השינוי.
• % או abs - לפרש את הסף כאחוז או ספירה מוחלטת.
• vs previous X window - גודל חלון ההשוואה. אפשרויות: 15m, 1h, 4h, 1d, 7d.
• Compare to - מול מה להשוות את החלון הנוכחי (ראו למטה). מוצג רק במצב Change.

השוואה ל- (השוואה עונתית)

במצב Change, ההתראה יכולה להשוות את החלון הנוכחי מול אחד משני בסיסים:

אפשרות	משווה את החלון הנוכחי מול…	מתאים ל
יום טיפוסי כמו היום (מומלץ)	החציון של אותו חלון 7, 14, 21 ו-28 ימים אחורה.	כמעט הכול, ובמיוחד התראות על ירידה באחוזים. מתמודד עם עונתיות שבועית, ומכיוון שזה חציון, יום גדול אחד לא מזיז אותו.
Immediately previous	החלון שקדם לו מיד (ברירת המחדל - ההתנהגות הרגילה כיום).	תעבורת API או Webhook שאין לה דפוס חזק לפי שעות היום.
Same window last week	אותו חלון בדיוק, שבעה ימים קודם.	אירועי משפך בעלי עונתיות שבועית או יומית (ברוב האפליקציות לצרכנים), שבהם השעה הקודמת עלולה ליצור התראת שווא.

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

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

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

היקף (אופציונלי)

צמצמו את ההתראה לפלח ספציפי:

• Inbound - הגבילו לפי API key (טוקן Bearer מסוים) ו/או endpoint (נתיב מסוים).
• Outbound - הגבילו לפי webhook URL. התפריט מתמלא מצומתי ה־Webhook הפעילים במסעות הפעילים ובטיוטות שלכם, כך שתבחרו יעד אמיתי במקום להקליד כתובת URL.
• Events - הגבילו לפי event name. הבורר מבוסס על אוצר שמות האירועים האמיתי בסביבת העבודה (200 שמות האירועים הנפוצים ביותר ב־30 הימים האחרונים, לצד הספירות שלהם). השאירו את האפשרות "all events" כדי לספור הכול; הבורר מושבת כשהמדד הוא Total events.

השאירו את ההיקף בברירת המחדל "all" כדי להעריך את כל סביבת העבודה.

תצוגה חיה מקדימה

הכותרת התחתונה בודקת באופן מחזורי נקודת קצה לתצוגה מקדימה באמצעות ההגדרות הנוכחיות ומציגה:

• Would fire now (אדום) - הערך הנוכחי של המדד כבר חוצה את הסף. שימושי לזיהוי הגדרות רגישות מדי.
• Healthy (ירוק) - הערך הנוכחי בתוך הסף.
• Paused (אפור) - המתג Enabled (בשלב 3) כבוי, ולכן ההתראה לא תופעל גם אם המדד יחצה את הסף.

התצוגה המקדימה אינה שומרת דבר ואינה שולחת הודעה. זו רק בדיקה מהירה.

שלב 3 - הודעה

תיבת סיכום כהה בראש הדף מסכמת על מה אתם מתריעים ("You're alerting on …"), עם קישור Edit חזרה לשלב 1.

ערוץ

בחרו כיצד לקבל הודעה כשההתראה מופעלת:

ערוץ אימייל (ברירת מחדל):

שדה	תפקיד
Email recipients	בחרו חברי צוות מתוך האנשים שלכם, או הקלידו כתובת חיצונית והקישו Enter או פסיק. לחצו על ✕ כדי להסיר. נדרש נמען אחד לפחות. כתובות חיצוניות לא מקבלות דבר עד שהן מאשרות - ראו כתובות חיצוניות חייבות לאשר. כלל שנוצר לפני שכתובות חיצוניות נדרשו לאשר מציג באנר עם שליחת אישור (פרטים).
	הודעה אחת נשלחת לכל נמען במעבר healthy → triggered. כל עוד ההתראה נשארת במצב triggered, הנמענים מקבלים תזכורת עדיין פעילה כל 4 שעות (עד 3 לכל תקרית), ואימייל נפתרה אחד כשהיא חוזרת לטווח התקין.

ערוץ Webhook:

שדה	תפקיד
Webhook URL	חובה. Joryio שולחת לכאן בקשת POST עם מטען JSON בכל פעם שההתראה מופעלת.
Signing secret	אופציונלי. Joryio חותמת כל בקשה באמצעות HMAC-SHA256(body) ושולחת את החתימה בכותרת X-Joryio-Signature, כדי שהמערכת המקבלת תוכל לוודא שהקריאה אכן הגיעה מ־Joryio.

תצוגה מקדימה חיה של המטען מופיעה במקטע קוד כהה ומכילה את שם ההתראה ואת המדד שהגדרתם זה עתה. ערוץ ה־Webhook שולח בקשת POST בשני המעברים (triggered וגם resolved), כדי שהמערכת המקבלת תוכל להתאים תקריות מקצה לקצה. תזכורות ה"עדיין פעילה" כל 4 שעות נשלחות באימייל בלבד. המסירה מנוסה שוב עד שלוש פעמים בהשהיה מעריכית. מבנה המטען המדויק מתואר במדריך ה־API לניטור.

Cooldown ומצב הפעלה

שדה	תפקיד
Cooldown	הזמן המזערי בין הפעלות חוזרות לאחר שהמדד חוזר למצב תקין. ברירת המחדל היא 10 דקות. אפשרויות: 5m, 10m, 30m, 1h.
Enabled	מתג. כשהוא כבוי, ההתראה נשמרת במצב Paused - היא לא תיבדק ולא תופעל.

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

לאחר השמירה, כל התראה נמצאת באחד מארבעה מצבים:

מצב	חזותי	משמעות
Healthy	תג בצבע טורקיז	נמצאת במעקב ואין חריגה.
Triggered	תג אדום פועם	המדד חצה את הסף וההתראה הופעלה. הודעה נשלחה לנמענים. בשורה מופיע פעילה מאז עם שעת תחילת התקרית.
Snoozed	תג אפור	מושתקת זמנית. תחזור אוטומטית למצב Healthy כשחלון ההשתקה יסתיים.
Paused	תג אפור	מושתקת ללא הגבלת זמן. לא תיבדק ולא תופעל עד שתחדשו אותה ידנית.

קצב הערכה

המעריך בצד השרת רץ מדי דקה (משך הזמן הקצר ביותר שאפשר לבחור בממשק הוא דקה אחת, ולכן בדיקה תכופה יותר רק תבזבז משאבי CPU).

בכל מחזור, עבור כל התראה מופעלת שאינה במצב Snoozed או Paused:

1. המערכת שואלת את מקור המדד (יומן בקשות API נכנסות, יומן מסירות Webhook יוצאות או טבלת האירועים) עבור חלון משך הזמן.
2. היא משווה את הערך הנוכחי לסף. במצב Change היא שואלת גם את חלון ההשוואה - החלון שקדם לו מיד או אותו חלון שבעה ימים קודם.
3. אם הערך חוצה את הסף → המצב משתנה ל־Triggered, שורת firing נכתבת ל־History והודעה נשלחת בערוץ שנבחר.
4. אם ההתראה עדיין פעילה והערוץ הוא אימייל → נשלחת תזכורת עדיין פעילה כשעברו 4 שעות מההפעלה או מהתזכורת הקודמת, עד 3 לכל תקרית.
5. אם ההתראה הופעלה והערך חוזר לטווח התקין → המצב משתנה ל־Healthy, שורת ה־firing האחרונה מסומנת כ־resolved ונוספת לה חותמת הזמן resolvedAt, ונשלח אימייל נפתרה (ערוץ אימייל) או בקשת POST מסוג resolved (ערוץ Webhook).

אופן הפעולה של Cooldown

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

Snooze לעומת Pause

• Snooze מוגבל בזמן (שעה, 4 שעות, 24 שעות או עד מחר בשעה 9:00). ההתראה מתחדשת אוטומטית כשהחלון מסתיים. השתמשו באפשרות זו כשאתם מודעים לבעיה ורוצים להשתיק אותה, למשל לארבע שעות.
• Pause אינו מוגבל בזמן. ההתראה נשארת מושהית עד שתלחצו ידנית על Resume. השתמשו באפשרות זו לכללים שאינם רלוונטיים כעת (לדוגמה, בחלון תחזוקה מתוכנן ללא תעבורה).

אפשר להשתיק התראה יחידה מתפריט ⋯ שבשורה, או ללחוץ על Snooze all בכרזה האדומה כאשר כמה התראות מופעלות בבת אחת.

הודעות על הפעלה

אימייל

כשהתראה בערוץ אימייל מופעלת, כל חבר צוות שבכלל וכל כתובת חיצונית שאישרה מקבלים הודעה עם:

• שם ההתראה בשורת הנושא (שלפניו סמל התראה).
• הערך הנוכחי של המדד (הערך שחרג).
• הסף שנחצה.
• תיאור ההתראה אם הוגדר.
• קישור חזרה אל Settings → Logs & Monitoring → Alerts.

כל עוד ההתראה נשארת פעילה, אותם נמענים מקבלים תזכורת עדיין פעילה כל 4 שעות, עם השעה שבה התחילה - עד 3 תזכורות לכל תקרית. כשהיא חוזרת לטווח התקין הם מקבלים אימייל נפתרה אחד. תקרית חדשה (אחרי פתרון) מתחילה את הספירה מחדש.

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

Webhook

כאשר התראה בערוץ Webhook משנה מצב, Joryio שולחת בקשת POST עם מטען JSON לכתובת ה־URL שלכם בשני המעברים - triggered ו־resolved. אם הגדרתם סוד חתימה, אמתו את הכותרת X-Joryio-Signature (ערך הקסדצימלי באותיות קטנות של HMAC-SHA256 המחושב על הגוף הגולמי) לפני שתתנו אמון בקריאה. מבנה המטען המדויק מתועד במדריך ה־API לניטור.

היסטוריה

הדף History הוא יומן הביקורת. כל מעבר (healthy → triggered, triggered → resolved) כותב שורה.

כל שורה מציגה:

• זמן - מתי המעבר קרה, עם זמן יחסי מתחת.
• התראה + תווית מצב - Firing, Resolved או Snoozed at fire.
• תמונת מצב של המדד - הערך שאליו הגיע המדד ברגע המעבר והסף שהיה מוגדר.
• תרשים זעיר - תרשים קטן של המדד סביב המעבר. אדום להפעלה, טורקיז לפתרון ואפור להשתקה.
• משך - משך התקרית (Ongoing אם היא עדיין פעילה).
• נמענים - מי קיבל הודעה, עם +N עבור הנמענים הנוספים. אם איש לא קיבל הודעה, למשל משום שההתראה הייתה מושתקת באותו רגע, מוצג silent בכתב נטוי.

מסננים

שלושה מסננים בראש הדף:

• Alert - הצגת אירועים עבור כלל התראה מסוים.
• State - Firing now, Resolved או Snoozed at fire.
• Period - 24h, 7d, 30d, 90d.

ארבעת אריחי הנתונים הסטטיסטיים שמעל לציר הזמן מציגים נתונים מצטברים של האירועים הגלויים לאחר הסינון:

Tile	מה הוא סופר
Firing now	תקריות פתוחות - המדד עדיין חורג.
Resolved (7d)	תקריות שנפתרו מעצמן או שאושרו בשבעת הימים האחרונים.
Mean time to resolve	משך הזמן הממוצע של תקריות שנפתרו.
Notifications sent	המספר הכולל של נמענים שקיבלו הודעה בכל האירועים שבחלון.

מה נמדד

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

Inbound API request log

• מה יש בו: כל בקשה אל ה־REST API של Joryio שאומתה באמצעות מפתח API. חותמת זמן, ארגון, סביבת עבודה, קידומת מפתח API, שיטת HTTP, נקודת קצה קנונית (לדוגמה /users/:id), קוד מצב ומשך.
• מה אין בו: תעבורה מלוח הבקרה (קריאות מממשק Joryio שאומתו באמצעות JWT), בדיקות תקינות ונתיבים פנימיים בלבד.

Outbound webhook delivery log

• מה יש בו: כל ניסיון Webhook שנשלח מצומת Webhook במסע משתמש. חותמת זמן, ארגון, סביבת עבודה, מסע, כתובת URL, קוד מצב התגובה (או 0 לשגיאות תעבורה כגון timeout), משך ומספר הניסיון.
• מה אין בו: הודעות Webhook שנשלחו לפני פריסת היכולת הזו (משימות ישנות בתור אינן נושאות את המטא־נתונים הנדרשים של הדייר; היומן מדלג עליהן בלי להכשיל אותן).

אירועים

• מה יש בהם: כל אירוע לקוח שה־SDK או האפליקציה שלכם עוקבים אחריו, לפי שם האירוע והמשתמש. זו אותה טבלת events ששאר הפלטפורמה קוראת.

בקרות יומן ושמירת נתונים

גם יומן בקשות ה־API הנכנסות וגם יומן מסירות ה־Webhook היוצאות ניתנים להגדרה לכל ארגון (צוות Joryio מנהל אותם במסוף הניהול):

• Kill switch - אפשר להפעיל או לכבות כל זרם יומן בנפרד עבור ארגון. כשהוא כבוי, לא נכתבות שורות והמדדים של הכיוון מפסיקים להתעדכן. ברירת המחדל של שניהם היא on.
• Retention - לכל זרם יש חלון שמירה משלו, בין 7 ל־365 ימים (ברירת המחדל היא 90). שורות נמחקות אוטומטית לאחר שחלפה תקופת השמירה של הארגון שלהן.

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

התראות בריאות אוטומטיות (ללא הגדרה)

בנוסף להתראות שאתם מגדירים בעצמכם, Joryio מנטרת ברציפות כל סביבת עבודה לאיתור תקלות באינטגרציה - ללא צורך בהגדרה:

• Flatline - אירועים זרמו ואז נעצרו בפתאומיות (מפתח SDK שאינו פעיל, פריסה פגומה או מקטע קוד שהוסר). מסווג כמצב קריטי.
• ירידה מתמשכת - נפח האירועים יורד הרבה מתחת לקו הבסיס הרב־יומי של סביבת העבודה. מסווג כאזהרה.
• זיהוי לפי אירוע - האירועים המשמעותיים ביותר שלכם (למשל purchase, page_view) מנוטרים בנפרד, כך שגם תקלה בשלב יחיד במשפך תזוהה כאשר הנפח הכולל נראה תקין.
• התנגשויות הודעות - המסעות והקמפיינים שלכם מגיעים לאותם אנשים באותו זמן. מועלה כ-אזהרה כאשר, ב-7 הימים האחרונים, לפחות 25% מהאנשים שקיבלו הודעה קיבלו שתיים או יותר באותו יום (ולפחות 50 אנשים קיבלו הודעה). ההתראה מציינת את השיעור, כמה מהם קיבלו בתוך שעה, ואת הקמפיינים או המסעות המעורבים ביותר. היא נסגרת מעצמה כשהשיעור יורד מתחת לסף. שום דבר לא נחסם. השיעור והמינימום ניתנים לשינוי בהגדרות → ניטור → התראות; 25% הוא ברירת המחדל כי אימייל ופוש לאותו אדם באותו יום נספרים כהתנגשות, ותוכניות רבות עושות זאת בכוונה.
• לקוחות קבועים שנעלמו - לא התראה אלא הסף של רעיון "לקוחות קבועים שנעלמו" בדף הבית, שנשמר כאן לצד התראת ההתנגשויות כי מדובר באותו סוג של ערך. הרעיון מופיע כשמספר הלקוחות הקבועים שדגל האיחור ברכישה שלהם נדלק השבוע מגיע לפחות לסף (ברירת מחדל 25) או לשיעור מהלקוחות הקבועים הפעילים (ברירת מחדל 2%), הגבוה מביניהם. עורכים את שניהם תחת הגדרות → ניטור → התראות; מדריך דף הבית מתאר את הכרטיס.

כשמתרחשת תקלה, תראו כרזה בדף הניטור ופריט בפעמון ההתראות, ותקבלו אימייל הכולל אבחון AI קצר - מה כנראה השתבש ומה כדאי לבדוק תחילה. האימייל נשלח לבעלים ולמנהלים של החשבון, וגם לחברים שההרשאות שלהם מאפשרות לשנות הגדרות בסביבת העבודה הזו, פעם אחת לכל תקרית. אם כבר הגדרתם לסביבת העבודה התראת Total events או Unique users משלכם, Joryio מדכאת את האימייל הכפול - ההתראה שלכם שולחת אימייל לנמענים שלה.

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

Cooldown והגנה מפני מגבלת קצב

התראות מופעלות לכל היותר פעם אחת בכל חלון Cooldown. אם מדד נשאר בחריגה במשך שעות, תקבלו את ההודעה הראשונה ואחריה תזכורת לכל היותר כל 4 שעות (עד 3), לא 60 הודעות בשעה, ועוד אימייל אחד כשהמדד חוזר לתקין. שעון ה־Cooldown מתאפס כשהמדד חוזר לטווח התקין.

אם השתקתם התראה, הפעלות שמתרחשות במהלך ההשתקה עדיין כותבות שורה ב־History (כדי שתוכלו לראות מה החמצתם), אך לא נשלחת הודעה ובשורה מוצג silent (snoozed) בעמודה Recipients.

בסביבת עבודה לדוגמה שהחיבורים החיצוניים שלה סגורים, התראות עדיין נבדקות ועדיין מופיעות באפליקציה - בפעמון, בסטטוס ההתראה, ביומן History (בעמודה Recipients מוצג silent) ובבאנר מעקב האירועים - אך שום אימייל או webhook לא נשלח, הן עבור כללי התראה והן עבור הזיהוי האוטומטי של מעקב האירועים. ברגע ש-Joryio פותחת את הסביבה לדוגמה לחיבורים חיצוניים, ההתראות שולחות הודעות כרגיל.

מגבלות

• ערוצים: יש תמיכה גם באימייל וגם ב־Webhook. אין ערוץ Slack מובנה - נתבו את התראות ה־Webhook של Joryio אל Slack באמצעות Webhook נכנס של Slack, או השתמשו באינטגרציות מבוססות אימייל לניהול תקריות (לדוגמה PagerDuty).
• דפי פרטים לכל אירוע: הכפתור View details בשורות ההיסטוריה גלוי, אך כרגע אינו מבצע פעולה.