Ask six platform engineers who owns alert hygiene at their company and you will get six different answers. You will also get six different definitions of what "alert hygiene" even means. This ambiguity is not accidental. It reflects a structural gap in how most organizations think about the monitoring lifecycle, and it is the primary reason why alert fatigue gets worse over time even as tooling investment increases.
Platform teams are usually responsible for the observability infrastructure: the Prometheus stack, the Grafana dashboards, the Alertmanager routing tree, the PagerDuty integration, maybe a Datadog account that the previous team set up. But they are almost never accountable for the quality of the alert rules that run on top of that infrastructure. Those rules are owned by product teams, inherited from former engineers, or simply accumulated over years without meaningful pruning.
The shared-infrastructure, distributed-rules problem
Most alert rules in a growing stack were written by someone who is no longer at the company. This is not an exaggeration. In an org with 2-3 years of Kubernetes operations history, the majority of alert rules in Prometheus were probably written by a handful of engineers who have since moved on. The rules were correct when written, for the system as it existed at that moment. Services have since scaled, thresholds have drifted, and the original context is gone.
Platform teams end up as de facto custodians of rules they didn't write and can't fully evaluate because they don't own the services those rules monitor. The product team that owns a service doesn't manage the alerting infrastructure and doesn't think of alert quality as their problem. The result is a kind of ownership vacuum where no one is wrong and nothing gets fixed.
We are not saying this is a failure of any individual. The incentive structure makes alert quality a tragedy of the commons. Each team benefits from comprehensive alerting coverage for their services. The cost of noisy alerting is paid by the on-call rotation, which is shared. No one team bears the full cost of their own noise contribution, so no one team has strong incentive to reduce it.
What platform teams can actually control
Platform engineering has more leverage here than it typically exercises. The observability infrastructure gives platform teams visibility into alert firing rates, actionability rates, and correlation patterns across the entire stack. That data is the foundation of any meaningful alert hygiene program.
The first concrete step is building a firing rate report by alert rule. For each rule in your Prometheus rule set, track how many times it fired in the past 30 days, what percentage of those firings resulted in a PagerDuty incident being opened, and what percentage of those incidents were resolved with a "no action required" note. A rule that fires 150 times per month and generates 2 actionable incidents is almost certainly misconfigured. That report, surfaced to the service team that owns those metrics, is a concrete and non-accusatory conversation starter.
The second lever is configuration standards. Platform teams typically own the template infrastructure for alert rules. If you provide Helm charts, Terraform modules, or internal tooling that helps product teams write alert rules, you can bake in best practices: a requirement for a playbook link, a suggested evaluation window, a recommended inhibition policy for post-deploy transients. This is not enforcement, it is defaults that raise the floor.
The inhibition problem and what it reveals
Alertmanager's inhibition rules are powerful but underused. The mechanism allows you to suppress lower-priority alerts when a higher-priority alert is already firing, which addresses one of the most common noise generators: a single root cause producing cascading alerts across dependent services.
In practice, inhibition rules require you to have a clear model of your service topology and alert priority hierarchy. Most organizations don't have that model written down anywhere accessible. It exists in the heads of a few senior engineers. Building inhibition rules therefore forces a useful exercise: mapping which services depend on which, and what a "parent" failure looks like versus a "child" failure.
Platform teams are well-positioned to drive this exercise because they have cross-service visibility. Product teams see their own services. Platform teams see all of them. The dependency mapping required for good inhibition rules is also valuable input for capacity planning, incident routing, and service reliability reviews, so the exercise has compound returns.
Creating a feedback loop between on-call and alert owners
The most important structural change a platform team can make is building a direct feedback channel from the on-call engineer to the alert rule author. This sounds obvious, but almost no organization has it. What most organizations have is a PagerDuty incident that gets resolved with a note, and that note goes nowhere useful.
A minimal version: when an on-call engineer marks an alert as "no action required," require them to tag a service label from a dropdown. That label routes a weekly digest to the service team: "Your
Explicit acknowledgment is fine, by the way. Some teams know their alert is noisy and keep it because it catches a rare but serious condition. That is a valid choice. What is not valid is that choice being implicit and invisible. Making the choice explicit means the team has accepted accountability for the on-call cost their noise generates.
Where tooling helps and where it doesn't
ObsrvHQ sits at a specific point in this ownership picture. We operate between the alert rule firing and the pager notification. That position gives us the ability to evaluate context: how often does this rule fire? Is this a post-deploy window? Are there correlated signals that suggest a shared root cause? If the pattern looks like noise in context, we suppress the page and log the event for review.
This doesn't fix the ownership problem. Rules that are genuinely misconfigured should still be fixed. Suppression is not a substitute for calibration. What it does is give platform teams breathing room: rather than alert hygiene being an emergency that demands immediate attention, it becomes a managed improvement process that happens in the background while the on-call load stays manageable.
The goal is a stack where service teams own the correctness of their alert rules, platform teams own the infrastructure and standards that make correctness achievable, and the detection layer handles the residual ambiguity that will always exist in a complex distributed system. That is a realistic steady state. Getting there takes clarity about ownership, not just better tooling.
Starting the conversation
If you want to move your org toward cleaner alert ownership, the most practical first step is naming the problem explicitly in a format that is data-driven rather than complaint-driven. Pull a report of your noisiest alert rules by actionability rate. Bring it to a platform team review with service team leads. Frame it as "here is where our alert coverage is weakest, how do we improve it together" rather than "your alerts are flooding on-call."
Platform teams that own this conversation and provide the data to drive it tend to get traction. Platform teams that wait for product teams to notice the problem on their own tend to wait indefinitely.