Slack کانال #alerts شبیه spam بود. CPU بالای ۷۰٪؟ alert. یک retry در queue؟ alert. deployment تمام شد؟ alert. نتیجه: وقتی دیسک واقعاً پر شد، کسی ندید — چون آخرین ۵۰ پیام همگی «اطلاعاتی» بودند.

یک روز error rate واقعاً جهش کرد و ۲۰ دقیقه طول کشید تا کسی واکنش نشان دهد. نه به خاطر بی‌تفاوتی — به خاطر alert fatigue. تیم یاد گرفته بود ignore کند.

با تیم نشستیم و یک قانون ساده گذاشتیم: alert باید actionable باشد — یعنی ساعت ۳ بامداد هم کسی باید بلند شود و کاری مشخص انجام دهد. اگر جواب «صبر کن خودش درست می‌شود» است، alert نیست.

alertهای informational را به dashboard منتقل کردیم، نه Slack. deployment success، CPU 65٪، pod restart بعد از deploy — همه می‌روند به Grafana. Slack فقط برای چیزهایی که نیاز به اقدام فوری دارند.

severity اضافه کردیم: P1 (کاربران affected)، P2 (degraded)، P3 (باید این هفته نگاه شود). P1 به تلفن on-call می‌رود، P3 فقط تیکت. بدون severity همه چیز فوری به نظر می‌رسد.

thresholdها را بر اساس baseline واقعی تنظیم کردیم — نه عدد magic از مستندات. یک هفته metric جمع کردیم، بعد alert گذاشتیم. CPU 70٪ برای یک سرویس lightweight معنی نداشت؛ برای batch job عادی بود.

on-call rotation گذاشتیم — حتی در تیم کوچک. یک نفر مسئول watch کردن P1/P2 در هفته خودش. burnout کمتر شد چون دیگر همه شب‌ها نمی‌ترسیدند گوشی vibrate کند.

کیفیت alert از کمیت مهم‌تر است. بعد از پاکسازی، تعداد alertها ۸۵٪ کم شد — ولی incidentهای واقعی سریع‌تر catch می‌شوند. عجیب نیست: وقتی کانال خلوت است، پیام جدید واقعاً دیده می‌شود.