Different client engagements over the years left us running production workloads across three different cloud providers, each with its own dashboard, its own alerting quirks, and its own terminology for the same underlying concepts. What one provider calls a load balancer target group, another calls a backend service, and a third calls something else entirely, and none of that terminology mismatch matters until you're trying to correlate an incident across all three at two in the morning.
A unified internal dashboard pulling metrics from all three into one consistent view has cut the time it takes to spot a cross-provider pattern, like a shared upstream dependency having a bad day, from a lucky guess to an actual visible correlation. Before this existed, noticing that three unrelated-looking incidents across three different client projects traced back to the same third-party API degrading required someone to happen to be watching all three dashboards at once, which basically never happened. Now the dashboard surfaces that kind of correlation on its own, because the underlying metrics are normalized into the same shape regardless of which provider they came from.
Building the normalization layer was the actual work here, and it was less glamorous than it sounds. Each provider's API for metrics and logs has its own quirks, rate limits, and blind spots, and getting latency, error rate, and saturation metrics into a genuinely comparable shape across all three took more iteration than we expected going in. We initially tried a thin pass-through layer that just relabeled fields, and it technically worked but produced a dashboard that still required provider-specific knowledge to interpret correctly, which defeated the point.
The version that actually stuck involved defining our own small set of canonical metric types up front, then writing a translation layer per provider that mapped their native metrics into that canonical shape, discarding provider-specific nuance that didn't generalize. That's meant losing a small amount of provider-specific detail in the unified view, which occasionally requires dropping into a provider's native dashboard for a genuinely provider-specific problem. That tradeoff has been worth it. The unified view is where nearly every incident review now starts, and the native dashboards have become a specialist tool for the minority of cases that actually need them, rather than the default first stop they used to be for everyone on the team.
Alerting was the harder half of this project, more so than the metrics visualization itself. Each provider's native alerting system has its own notion of thresholds, its own escalation logic, and its own quirks around alert suppression during known maintenance windows, and none of that maps cleanly onto a single unified rule set without real compromise somewhere. We ended up keeping alert routing decentralized, each provider still fires its own alerts through its own system, but feeding a normalized summary of every fired alert into the same dashboard so an on-call engineer sees one combined timeline regardless of which provider's alerting system actually triggered.
That decision, keeping alerting decentralized while unifying observation, was a deliberate compromise rather than an ideal outcome, and we've revisited it more than once. A fully unified alerting system, where a single rule engine evaluates thresholds across all three providers identically, would be cleaner in principle. We haven't built it because the engineering cost is substantial and the current compromise already delivers most of the practical benefit: an on-call engineer no longer needs to remember to check three separate places during an active incident, which was the actual problem we set out to solve. We may still build the fully unified version eventually, but it hasn't been the highest-value place to spend engineering time relative to everything else competing for that time.