Since we have a wide array of individuals here I thought we could create a thread to post resumes and see if we can get some community feedback. I have posted mine(ignore the 2 page spread), lets if anyone else wishes to receive feedback on there's. @Ryan Nolan @Matt Payne

Hi guys, I am using SerpAPI to do a Google Maps search in n8n for companies on the internet, and I am wondering if there is a way to only search for companies that have a website, instead of searching for loads of companies and then filtering through the ones that have a website, as this uses more executions?

If you are working with RAG in n8n workflows I highly suggest reading this article: https://www.nicolasbustamante.com/p/the-rag-obituary-killed-by-agents As a RAG expert myself I found the approach very interesting in what I know from experience is a difficult domain.

Today starts my road to learn n8n from scratch... I use to work with Manychat. I love learning, teaching and working using all I know.

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