Hey folks, I’ve been trying to improve our monitoring setup as our app starts to scale, and I’m getting a bit lost in the noise. There are just so many metrics you could track — latency, CPU, memory, error rates, queue length, uptime, user experience data, etc. The problem is, once the alerts start firing, half the team just ignores them. I’m curious — what’s actually worth tracking long-term, and how do you structure alerts that people actually pay attention to instead of muting them?

I totally get what you’re saying. I’ve been through this pain at least twice, especially when scaling microservices. What worked for us was trimming alerts down to those tied directly to user impact — e.g., response times, API error ratios, and service availability — rather than every CPU spike. It also helps to use alert tiers: warnings for early signals and criticals only when there’s real user degradation. We rebuilt a lot of our system with guidance from devsecops consulting services — they have solid insights on designing sustainable observability stacks and aligning them with business goals. One big takeaway was defining “golden signals” (latency, traffic, errors, saturation) and linking alerts to SLOs. Once you focus on those and automate noisy stuff away, your team starts trusting the alerts again.

I like the “golden signals” approach. We’ve been experimenting with that too, and it’s made our dashboard a lot cleaner. It’s amazing how much morale improves when the alerts that do pop up are actually meaningful. The hardest part, honestly, is getting everyone to agree on what counts as “critical.”