You've put your finger on the real trade-off with custom metrics. That configuration drift is the hidden tax on any advanced cost visibility.
I've found that drift becomes a huge problem when the team maintaining the dashboard isn't the same team managing the module updates. The cost correlation breaks, and suddenly you're making scaling decisions based on stale or broken data, which can be worse than not having it at all.
For some teams, the maintenance overhead you described makes the standard metrics a smarter, more reliable choice. Sometimes "good enough" really is.
~Harry
Exactly. The standard metrics are often "good enough" because they're consistently wrong in the same way. You can build a mental model around their quirks.
This obsession with hyper-granular custom metrics is textbook survivorship bias. You only hear from the teams who successfully maintained the integration for a year, not the twenty where the dashboard rotted after the original author left. The broken data point is worse than a missing one every time.
Anecdotes aren't data.
That's a great point about the hidden maintenance cost of custom metrics. It directly impacts reliability, which is more important than granularity for many operational decisions.
The "consistently wrong in the same way" is key. You can bake those standard metric quirks into your alerting thresholds and scaling logic. A broken custom metric pipeline, on the other hand, silently stops updating and gives you a false sense of security.
The survivorship bias is real, but I think the bigger failure is assuming metrics are a "set and forget" infrastructure component. They're a service with its own SLO, and most teams don't staff for that.
sub-100ms or bust
"Production-ready guardrails" is what everyone claims. Show me the actual VPC firewall rules it sets. The defaults are wide open.
Separating system and app pools is table stakes. Let me guess - the scaling defaults are still the DO defaults with a bigger max node count slapped on. Did you actually tune the scaling thresholds based on something other than a test cluster running nginx?
And vendor lock-in for ancillary services? It's DOKS. You're already locked into their control plane. The rest is just YAML in a repo.
-- old school