We resolved a production alerting issue in our n8n monitoring system — and it reinforced some important lessons about reliability and data governance. The issue Our monitoring workflow was repeatedly sending WhatsApp alerts for services that hadn’t actually changed status. The result was unnecessary noise, reduced trust in alerts, and operational distraction. Why it mattered Teams started ignoring alerts (classic alert fatigue). Monitoring reliability was questioned. Sensitive infrastructure data risked being logged or shared unintentionally. What we changed Implemented a persistent, external source of truth so alert state survives restarts and redeployments. Cleanly separated runtime logic from stored state, improving stability and predictability. Strengthened health-check validation to correctly handle timeouts and errors. Ensured alerts and logs are generated only from verified system state, not third-party responses. Added rate-limiting and redaction controls to prevent duplicate alerts and protect infrastructure details. The result Alerts now trigger only on real service status changes. Monitoring remains stable across deployments. No sensitive endpoint data is stored or shared. Higher confidence in alerts and faster response when issues actually occur. This was a good reminder that monitoring isn’t just about uptime — it’s about signal quality, resilience, and trust. If you’re using n8n or similar tools and struggling with noisy alerts or unreliable state, happy to share a sanitized workflow and a production-readiness checklist. Feel free to DM