איתור תקלה במסירה שנכשלת
איך קוראים את ציר הזמן: מה כל קוד סטטוס אומר בדרך כלל, ומה עושים איתו.
בקצרה
- מתחילים מציר הזמן של הניסיונות: הסטטוס, זמן התגובה וגוף התשובה, הכל נרשם.
- 401 בדרך כלל אומר שסוד החתימה הוחלף; timeout בדרך כלל אומר שהצרכן עושה את העבודה לפני שהוא עונה.
- תקינות היעד (endpoint) נותנת אחוז הצלחה ואחוזוני זמן תגובה ליממה האחרונה.
| # | שעה | סטטוס | קוד | זמן תגובה | למה |
|---|---|---|---|---|---|
| 1 | 09:41:02 | נכשל | 503 | 1,204 ms | השירות לא זמין |
| 2 | 09:41:07 | נכשל | 503 | 980 ms | ניסיון חוזר אחרי 5 שניות |
| 3 | 09:41:37 | נכשל | timeout | 15,000 ms | ניסיון חוזר אחרי 30 שניות |
| 4 | 09:46:37 | נמסר | 200 | 142 ms | ניסיון חוזר אחרי 5 דקות |
אותו webhook-id בכל ניסיון, כך שהצרכן יכול לסנן כפילויות.
קודם קוראים את ציר הזמן
כל ניסיון שומר את סטטוס ה-HTTP, את זמן התגובה, את סוג השגיאה אם לא התקבל סטטוס בכלל, ואת הקילובייט הראשון של גוף התשובה. רוב השאלות נענות עוד לפני שפותחים לוג בצד השני.
הסדר הזה חשוב. כשלקוח כותב "לא קיבלנו את האירוע", הנטייה הטבעית היא לחפש בקוד של הצרכן. אבל ציר הזמן כבר יודע אם הבקשה יצאה, מתי, מה חזר ותוך כמה זמן. גוף התשובה לבדו פותר הרבה מקרים: הודעת שגיאה של מסגרת הפיתוח, עמוד שגיאה של פרוקסי, או תשובה מהשרת הלא נכון.
curl https://api.hookget.com/v1/events/msg_…/attempts -H "authorization: Bearer $HOOKGET_KEY"מה התשובות הנפוצות אומרות
| סימפטום | הסיבה הנפוצה | מה עושים |
|---|---|---|
| 401 או 403 מהיעד | הצרכן מאמת מול סוד חתימה ישן | בודקים אם הסוד הוחלף והצרכן עדיין מחזיק את הקודם |
| הצרכן מדווח שהחתימה לא תואמת | הגוף פוענח וסודר מחדש לפני האימות | מאמתים על הבתים הגולמיים |
| timeout | הצרכן עושה את העבודה לפני שהוא עונה | קודם מאשרים, אחר כך מעבדים |
| 5xx לסירוגין | פריסה, או תלות של הצרכן | כלום. לוח הניסיונות החוזרים קיים בדיוק בשביל זה |
| הכל נכשל מרגע מסוים | DNS, תעודה שפגה או שינוי בחומת האש | בודקים את היעד ישירות מחוץ לרשת שלכם |
| שום ניסיון לא בוצע | אין יעד פעיל שנרשם לסוג האירוע הזה | בודקים את מסנן סוגי האירועים על היעד |
שתי השורות הראשונות הן אותה בעיה בשני לבושים: הצרכן מחשב חתימה על משהו אחר ממה שנחתם, בגלל סוד שונה או בגלל בתים שונים. במדריך אימות החתימות יש פונקציה שמאמתת על הגוף הגולמי. השורה האחרונה היא המבלבלת ביותר, כי אין כשל לראות: האירוע פורסם, אבל אף יעד לא היה אמור לקבל אותו.
תקינות היעד
curl https://api.hookget.com/v1/endpoints/ep_…/health -H "authorization: Bearer $HOOKGET_KEY"
# success rate over 24h, p50 and p95 latency, consecutive failures,
# and the reason if it has been disabledהתשובה כוללת אחוז הצלחה על פני 24 שעות, זמני תגובה p50 ו-p95, מספר כשלים רצופים, והסיבה אם היעד הושבת. המספרים האלה עונים על שאלה אחרת מציר הזמן: לא "מה קרה לאירוע הזה" אלא "האם היעד הזה בריא בכלל".
גם עוזר AI יכול לקרוא את הנתונים האלה: שרת ה-MCP חושף כלי diagnose שמשלב את בדיקת הכתובת,
את מצב המפסק ואת נתוני התקינות לאבחנה כתובה במילים.
שאלות
מאיפה מתחילים כשמסירת וובהוק נכשלת?
מציר הזמן של הניסיונות. כל ניסיון שומר סטטוס, זמן תגובה, סוג שגיאה אם לא היה סטטוס, ואת הקילובייט הראשון של גוף התשובה, ורוב השאלות נענות שם.
למה היעד מחזיר 401 אחרי שהכל עבד?
בדרך כלל כי סוד החתימה הוחלף והצרכן עדיין מאמת מול הסוד הקודם. בודקים אם הייתה החלפה ומעדכנים את הסוד אצל הצרכן.
מה גורם ל-timeout במסירה?
לרוב הצרכן עושה את כל העבודה לפני שהוא עונה. הפתרון הוא לאשר קודם ולעבד אחר כך, כדי שהתשובה תחזור מהר גם כשהעבודה עצמה ארוכה.
צריך לעשות משהו עם שגיאות 5xx לסירוגין?
בדרך כלל לא. הן נובעות מפריסה או מתלות של הצרכן, ולוח הניסיונות החוזרים קיים בדיוק בשביל זה.
אירוע פורסם ואין אף ניסיון מסירה. למה?
כנראה אין יעד פעיל שנרשם לסוג האירוע הזה. בודקים את מסנן סוגי האירועים על היעד, וגם אם היעד מושהה או מושבת.
להתחיל למסור וובהוקים היום
מפנים את הוובהוקים ל-HookGet ורואים את המסירה הראשונה מגיעה, חתומה, תוך פחות מדקה.
פתיחת חשבון חינם לנסות את בודק הוובהוקים החינמי
10,000 מסירות בחודש בחינם, בלי כרטיס אשראי. המסלול החינמי חוסם ולא מחייב, כך שניסיון לא יכול להסתיים בחשבונית.